We have Liftoff!

Three years ago, in January of 2021, Merlin Ventures opened our office in Tel Aviv with a goal of finding the best early-stage cyber startups in Israel and bringing them to the US market. But nearly 25 years before that, our sister company, Merlin Cyber, opened its office in the US, and has continued to grow its business of helping companies succeed in the US Government market.

Over the last few years, however, we’ve seen a challenge in bringing companies into the government market. As the majority of companies moved from offering on-prem software to being SaaS-first and eventually to being SaaS-only, we were hitting a very big snag. While on-premise products could be sold to government agencies with relatively little required in terms of security compliance, cloud-based solutions fall under a compliance requirement called FedRAMP that regularly takes years to complete and costs millions of dollars. Even for late-stage, public companies, it’s a huge barrier to entry. For innovative, early-stage companies it’s a showstopper.

And so, three years ago, around the same time we started building out Merlin Ventures’ presence in Israel, Merlin Cyber started working on a project with the goal of significantly reducing the burden of getting through FedRAMP to allow partners to enter the government market and speed up their time to revenue.

Today, we are excited to announce that that project, Constellation GovCloud®, has achieved its Provisional Authority to Operate (P-ATO) from the US Government and is now open for business.

What does that mean for software companies? Constellation is unique in its ability to accelerate a company’s path through the FedRAMP process. In addition to offloading the majority of compliance tasks, it reduces a partner’s compliance costs as their revenues grow in the public sector market. Constellation partners get a lower cost, more predictable path through the FedRAMP process, while relying on a team of experts that handle the hardest parts of the journey.

Constellation GovCloud® is meant to bring the best software innovation into the US government market, and is not limited to Merlin Ventures portfolio companies. But on the Merlin Ventures side of things, we are very excited about the possibilities Constellation GovCloud opens up to help accelerate our portfolio companies’ entry into the massive US Federal, State and Local government markets.

Today our portfolio companies will tell you the greatest value Merlin Ventures brings is around understanding US commercial markets and getting early customer traction, and that isn’t changing. But with Constellation GovCloud®, that’s only half the story. We invest in the most innovative companies in the world, and with Constellation, we’ve just opened up a massive, untapped market for them.

Dig Security, Talon Cyber Security Acquired by Palo Alto Networks

Over the last month, I’ve been asked by many people how the Israeli companies we work with are doing. I tell them that everyone in Israel has been impacted in some way by the war, some more than others. But I also tell them the message that Israeli founders keep asking me to pass on: As much as they may be hurting emotionally, and while they may be short staffed due to employees being called up by the military, the Israeli tech community is open for business. Employees of companies that are short staffed due to military deployments are pitching in to make sure products still work and customer deliveries happen. The rallying cry of the startup community has become, “Israeli tech delivers, no matter what!

It’s with that backdrop that we share this past week’s two proof points: Palo Alto is acquiring two of our portfolio companies, Dig and Talon, for a combined value of nearly $1 billion. It’s quite a week for our young fund. Either of these exits on its own would be amazing news, but two of them so close together serves as proof of just how resilient Israeli businesses are.

To be fair, neither of these companies is ordinary. Both have exceptional founders who have built and sold businesses before. Both run their companies with remarkable discipline. And each of the founders has a drive that is hard to keep up with.

Dig was an early test of our vetting model, discussing startups we were considering with our network of US cybersecurity leaders to get their feedback. We had around 40 of our advisors on our call that day, and as we discussed a few companies it was quite clear that the excitement was around Dig. Over a quarter of the people on the call asked for an intro to the company, and that conversation became a big driver in our decision to invest. Seeing CEO Dan Benjamin and the rest of the team operate over the last year and a half has been a lesson in how to run a company.

Talon was not the first enterprise browser company we spoke to, and frankly we spent a lot of time prior to meeting with Talon trying to understand why this market even existed. But sitting with Ofer and hearing directly from him why he had built this company made it click. It didn’t hurt that most of the CISOs we talked about it with were in love with the concept. Once we understood why we needed an enterprise browser, deciding that Talon was the one to invest in was not a hard decision, given their vision, their team and their founders.

Notably, Talon’s acquisition marks the third exit for Merlin Ventures Israeli portfolio companies in just the last six months – joining Dig and Enso. Our congratulations to these founders and each member of their remarkable teams!

The Israeli tech community remains resilient even in the face of conflict and adversity, and it is inspiring to us see how they have taken up the rallying cry of “Israeli tech delivers, no matter what.”

Why we dig Dig

Today Dig Security is coming out of stealth, and we are excited to be joining them in their journey as an investor and partner. Like most VCs, we talk to a lot of startups, and it’s often a difficult decision about whether this is “the one” that we want to commit to. For Dig, it was surprisingly easy. From our first conversation, it was clear CEO Dan Benjamin was an expert storyteller who could clearly lay out the problem at hand, why it needed to be solved, and why Dig was the team to solve it. The three co-founders, Dan, Ido Azran and Gad Akuka (first initials D-I-G — get it?), are all second-time founders tackling a problem they have first-hand knowledge of based on their previous roles

Databases have been with us since the 1960s. During those 60 years, we’ve seen massive changes in the way databases work, the types and volume of data they store, and where they store it. We’ve also seen a massive movement toward monetization of data, both by legitimate enterprises and criminal organizations, making those datastores juicier targets than ever.

As the cloud becomes the default place to spin up new datastores and migrate old ones, we need to rethink not just data storage, but data security in general. We cannot continue to rely on models that were designed before S3 or Database-as-a-Service was a thing. On-premises solutions were designed for different attack vectors and rely on different network and endpoint capabilities. Dig is rethinking data security from the ground up with a focus on what new risks and opportunities cloud brings.

It’s been a while since I’ve been a database administrator, and that’s probably for the best. The threats today’s DBAs, Chief Data Officers, and security teams need to defend against are a lot more dynamic than I ever had to worry about. I hope that by working with Dig, the industry’s first data detection and response (DDR) solution, we can help make their jobs a bit easier.

Merlin Ventures featured on N12 panel at Israeli Cyber Conference

Earlier this week, Merlin Ventures Managing Partner Shay Michel participated in a panel discussion about Israel as a cyber nation. The discussion was broadcast on the news channel N12 and you can watch Shay’s appearance in the recording below (in Hebrew).

Read more

Cyolo’s pressure-free guide to getting started with zero trust

This post was originally published in Cyolo’s blog. Cyolo is a Merlin Ventures portfolio company.

Read more

4 things that can help your startup achieve Gartner Cool Vendor recognition

Since 2004, being named a Gartner “Cool Vendor” is something every technology startup aspires to. As one of Gartner’s most popular programs, Cool Vendors shines a spotlight on new and emerging small companies. Startups will pore over guides about how to work with Gartner or look for insider secrets to becoming a Cool Vendor—doing anything they can to improve their chances of earning the coveted status. 

Read more

Advice for young startups eyeing federal: What kind of tech does the U.S. Government need?

High-profile cyberattacks against federal systems and critical infrastructure underscore the importance and urgency of strengthening U.S. cybersecurity capabilities. The landmark bipartisan Infrastructure Investment and Jobs Act of 2021 (IIJA) (H.R.3684), signed into law this week, includes about $2 billion in cybersecurity funding for new cybersecurity initiatives across Federal, State, Local, Tribal and Territorial governments. While the investment is welcome, sadly even $2 billion will not make our government systems immune to attack. The scope of the attack surface and dynamic nature of the threat environment make holistically strengthening cybersecurity a complex endeavor. Equally important, high levels of technical debt resulting from a reliance on legacy systems further hinder modernization efforts

Given the scope and scale of the federal government, building momentum for modernization efforts can be daunting. The Executive Order (EO) on Improving the Nation’s Cybersecurity, issued in May of this year, responds to this challenge by laying a foundation for progress. With its focus on pushing organizations, both in government and industry, to follow best practices for maturing cloud adoption and zero trust, as well as enhancing software supply chain security, the EO has the potential to drive significant advancements in security and resiliency across the federal enterprise.

Adopt security best practices

Recognizing that modernization done right drives security advancements, the EO prompts agencies to:

  • Adopt a cloud-service governance framework
  • Implement a zero-trust network architecture (ZTNA)
  • Enhance software supply chain security

Adopt a cloud-service governance framework

Fundamentally, the EO encourages agencies to continue their cloud adoption journey by transitioning to Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS). The migration of legacy IT systems to secure cloud services can have cascading positive impacts on agency operations as systems are updated to take advantage of native capabilities around resiliency and reliability; protection of sensitive data; and proactive threat detection, prevention, and response. As agencies move forward in adopting a cloud-governance framework, they will need to reevaluate their approach to security, and in many cases adopt new types of technologies that were not needed in legacy architectures. This presents an opportunity for startups, as often there is no incumbent in place yet in the Federal market, and agencies may be more willing to take a risk on an earlier stage company. For example, agencies may never have had a significant need for Cloud Security Posture Management (CSPM), Cloud Workload Protection Platform (CWPP) or Infrastructure as Code (IaC) solutions to date, but as the balance of on-prem to cloud shifts, these become vital parts of a security architecture. Similarly, with the cloud making old concepts of network boundaries obsolete, identity is being described as the new perimeter, opening opportunities for novel approaches to identity and access management. And those identity solutions play a big part in our next section, zero-trust.

Implement a zero-trust network architecture

Zero trust is now an integral part of the federal government’s strategy to strengthen cybersecurity in the face of increasingly aggressive and resourceful attackers. In addition to being a multi-year journey, the move away from perimeter-based network defenses toward zero trust security principles of ‘never trust, always verify,’ will require a major paradigm shift in how federal agencies approach cybersecurity. Throughout all aspects of the infrastructure, zero trust embeds security monitoring, security automation, microsegmentation, and granular access controls based on risk to limit access to only what is needed. DHS’ Cybersecurity and Infrastructure Security Agency (CISA) has put together a zero trust architecture that defines five pillars agencies must consider in a mature zero trust architecture:

  • Identity
  • Device
  • Network/Environment
  • Application Workload
  • Data

Each of these pillars plays a vital role, and there is room for innovation in all of them. Identity in particular is a key foundation to a successful zero trust implementation, so better approaches to existing identity solutions like Identity and access management (IAM), Privileged access management (PAM) and Single sign-on (SSO) are needed. CISA’s maturity model for zero trust pushes for a future that is more reliant on continuous monitoring and validation across all pillars, real-time risk analysis, and improved machine learning capabilities to allow these systems to make better, faster decisions.

Enhance software supply chain security

Modernizing federal cybersecurity is just one element of the EO. It also results in a monumental shift in supply chain security requirements by establishing baseline security standards for any software—especially critical software—sold to the federal government. Per the EO’s directive, during the initial phase of the EO’s implementation, products identified as critical software will have to meet the technical requirements issued under Section 4(e) of the Executive Order.

Further, aiming to protect government agencies from the risk of supply chain software attacks, the EO calls for the National Institute of Standards and Technology (NIST) to create new supply chain security protocols and establish best practices, guidelines, and criteria for the future standards that software suppliers will need to comply with to be able to sell software to the federal government. This in and of itself may be the most impactful element of the entire EO, with a potential to improve both government and private sector systems. The EO does not mandate commercial industry change how they handle software supply chain security, but by instead using the carrot of federal government acquisitions, the EO has the potential to finally push much of the commercial software market to change their thinking on the importance of securing their development process.

While many of the software supply chain security requirements are high level, with more detail to be developed by NIST over time, the EO does give some insight into what the expectations for future software products will be. These include, among other things:

  • Employing encryption for data
  • Employing automated tools to maintain trusted source code supply chains, ensuring the integrity of code
  • Automated vulnerability discovery and remediation
  • Maintaining provenance of all software code or components, and implementing controls on internal and third-party components and tools used in the development process

As you can see above, one notable element of the new requirements is for more visibility into the software development process. Any organization that provides software meeting NIST’s definition of critical software will need to provide a Software Bill of Materials (SBOM) that attests to product and supply chain security. An SBOM is a machine-readable document that lists all components in a product. The SBOM ingredient list includes every library—both open-source software (OSS) and commercial off-the-shelf (COTS)—that is included in an application’s code as well as services, dependencies, compositions, and extensions.

We realize the EO can be complex topic, but understanding it will help you understand where to focus your efforts when bringing your capabilities into the Federal market. For help on navigating the Executive Order’s key requirements, deadlines, and solutions, we encourage you to visit Merlin Cyber’s Cyber EO Resource Center.

As agencies mature their cloud adoption; transition from protecting well-defined networks to securing blurry, fluid perimeters; and pivot from trusted systems to zero trust, the need to embrace new, innovative technologies capable of protecting identities representing people, services, and devices on-prem and in the cloud has never been more urgent. The government undoubtedly has a large task ahead of it as it works to modernize its approach to cybersecurity and adopt strategies to ensure ongoing mission success. Its best hope in doing so is to leverage the capabilities being developed by today’s and tomorrow’s startups.


Advice for young startups eyeing federal: Do certifications matter?

One of the things we pride ourselves on at Merlin Ventures is preparing our portfolio companies for the federal market. What that means varies by company, but one area we like to focus on up front is helping you to understand the various federal certifications that exist (there are a bunch!) and which ones you actually need to be concerned about. Perhaps even more important than understanding which certifications matter is developing a timeline that makes sense for your company. Getting it right means you are prepared to take orders when customers are ready to place them. Getting it wrong means potentially wasting hundreds of thousands of dollars on a certification that may expire before it ever helps you.

My goal in this blog post is to spotlight four key certifications. That’s not to say you should drop everything in your roadmap and refocus your engineering team on these immediately. Rather, these are some of the more common ones we see and companies interested in federal should have a plan to address them at the right time.

Before diving into certifications, I should probably clarify that “certifications” isn’t even necessarily the right word. There are a few terms to be aware of, and sometimes they are used interchangeably when they should not be.

  • Compliant – A pretty low bar, compliance means you are following the rules, but no one has verified what you are doing. You’ll see this quite often with companies claiming to be FIPS (Federal Information Processing Standards) compliant, which should not be confused with being FIPS validated.
  • Validated or Certified – This is where a third-party has inspected what you are doing, validated that it does in fact meet the requirements, and certified the results. While validation is technically part of a certification process, these two terms are often used interchangeably. Most notably, you will typically see products referred to as being FIPS validated, meaning they have gone through the FIPS testing process and been shown to meet the requirements.
  • Authorized – This typically refers to a government agency validating that your solution meets their agency requirements and authorizing it for use. You will often see this referred to as an ATO, or Authority to Operate. While getting one ATO can often help you get others, ATOs refer to specific implementations and are not a stand-alone product certification.


Section 508 Compliance and VPAT

Section 508 of the Rehabilitation Act provides accessibility guidelines and requires that information and communications technology (ICT) used by the federal government or organizations funded by the federal government be in compliance with the law. Compliance, while mandated, is self-regulated as there is neither a certification process nor a certification authority that evaluates and attests to compliance.

To assist organizations in demonstrating compliance, the Information Technology Industry Council (ITI) has established a template called the Voluntary Product Accessibility Template (VPAT). A VPAT is a document that explains how ICT products such as software, hardware, electronic content, and support documentation meet laws and standards for IT accessibility. If your organization wants to conduct business with the federal government, you will need a VPAT. While self-assessment is possible, it can be complicated to complete the form internally without substantial accessibility experience. Firms therefore often rely on accessibility consultants to conduct a full audit and check for all applicable portions of Section 508, which includes the technical requirements; the functional performance criteria; and the information, documentation, and support requirements. While this is a requirement for selling into many agencies, the good news is that getting a VPAT is relatively easy and inexpensive.

Federal Information Processing Standard (FIPS) 140-2/140-3 Cryptographic Certification

FIPS 140 is a set of security requirements defined by the National Institute of Standards and Technology (NIST) for cryptographic modules deployed in the federal government. FIPS 140 accreditation validates that hardware and software cryptographic modules produced by private-sector firms meet requirements designed to protect a module from being altered, cracked, or otherwise tampered with. FIPS 140 validation is mandatory for federal agencies that collect, store, transfer, share, and disseminate sensitive but unclassified (SBU) information and extends to their contractors and service providers.

While FIPS 140-2 has been the standard for the last 20 years, FIPS 140-3 was approved on March 22, 2019 as the successor to FIPS 140-2 and became effective on September 22, 2019. Both FIPS 140-2 and FIPS 140-3 are accepted as current and active, but there are some gotchas to be aware of. While FIPS 140-2-certified modules will be valid until September 21, 2026, unless you are already in the queue, you can no longer apply for FIPS 140-2 validation in the traditional ways. (I say “the traditional way,” because there are some loopholes that still allow you to get a FIPS 140-2 certificate.)

Both FIPS 140-2 and FIPS 140-3 define four security levels, depending on the level of security that is needed. For most commercial software products, we find that level 1 is appropriate. However, FIPS is one place where the difference between “compliant” and “validated” comes into play. While there is some debate about it, many federal agencies will accept software so long as the encryption libraries it uses are FIPS 140 validated, which means the overall solution is compliant. However, some agencies will require that the entire product receives its own validation. We typically recommend our partners set themselves up to be able to go through the validation process, if necessary, but stick with compliance until they get to that point. While the standard FIPS validation process is extremely lengthy, there are some alternative approaches that we can recommend that can get companies through the process in a couple of months if it becomes necessary.

National Information Assurance Partnership (NIAP) Common Criteria Certification

Operated by the National Security Agency, NIAP is responsible for U.S. implementation of the Common Criteria, including management of the NIAP Common Criteria Evaluation and Validation Scheme (CCEVS) validation body. NIAP’s mandate is to provide neutral third-party testing of Commercial Off The Shelf (COTS) Information Assurance (IA) and IA-enabled IT products used in National Security Systems (NSS). NIAP certification is mandated by federal procurement requirements (CNSSP 11) for layered COTS product solutions to protect information on NSS and is most applicable to the Intelligence Community (IC), Department of Defense (DoD), and DoD contractors or affiliates.

NIAP evaluations are conducted by Common Criteria Test Labs (CCTLs) that are accredited by the NIST National Voluntary Laboratory Accreditation Program (NVLAP). All products evaluated under NIAP must demonstrate exact compliance to the applicable Protection Profile (PP), which is an implementation-independent set of security requirements and test activities for a particular technology that enables achievable, repeatable, and testable evaluations. Evaluations can be completed in less than 90 days, but must not exceed 180 days.

Common Criteria evaluation includes both cryptographic and non-cryptographic security functions of an IA or IA-enabled COTS IT product. In many cases, the cryptographic portion of a product will be evaluated under FIPS 140-2/FIPS 140-3. To eliminate duplicate test activities, NIAP accepts Cryptographic Algorithm Validation Program (CAVP) and CMVP certificates to demonstrate compliance to certain test requirements. To be posted on the NIAP Product Compliant List (PCL), the product’s cryptography must have a CAVP certificate, and optimally, a CMVP certificate. A NIAP certificate indicates that the product has successfully completed an evaluation and complies with the requirements of the NIAP program and, where applicable, the requirements of the FIPS validation program.

If and when to pursue Common Criteria certification is dependent on where you expect to sell your product within the U.S. Government. As mentioned above, while much of DOD will require it, most civilian agencies do not.

Federal Risk and Authorization Management Program (FedRAMP)

Established in 2011, FedRAMP is one of the government’s most rigorous security compliance frameworks. FedRAMP provides a standardized approach to security assessment, authorization, and continuous monitoring for commercial cloud products and services used by the U.S. government. While difficult to achieve, the beauty of a FedRAMP ATO is that it qualifies a cloud service offering (CSO) to be used at multiple agencies.

Before a CSO can be used by a federal agency, it must demonstrate compliance with all FedRAMP requirements, which are outlined in NIST 800-53. Additionally, a cloud service provider (CSP) must implement continuous monitoring and regular evaluation against this standard to maintain its status.

Because of the various gates that are part of the process, FedRAMP typically takes at least six months to get through, although it’s not unheard of for companies to take two years to complete it.  For SaaS-only products, FedRAMP can be a significant barrier to entry to the federal market, and it’s one that’s important to plan for. Even before a company is necessarily ready to invest in going through the formal process, there is pre-work that can be done to set yourself up for success, and understanding that timeline is key to entering the federal market at the right time.

Merlin has built out its own FedRAMP managed service called Constellation GovCloud to help companies get through the process more easily. If you’re looking for more info on FedRAMP, the Constellation site and blog are great sources of information.

Section 508, VPAT, FIPS, NIAP, FedRAMP… In this world of regulations that read like alphabet soup, we understand the challenges of complying. A big part of taking on the federal market is knowing when is the right time to pursue critical certifications. If you’re uncertain which standards you need to comply with – and when – we’re here to help.



Advice for young startups eyeing federal: Does the U.S. Government buy Israeli tech?

With many Israeli startup founders coming out of Unit 8200 and other cybersecurity-related groups within the Israeli military, the solutions they develop are often a natural fit for the types of threats government agencies face. As a result, it’s not surprising that Israeli CEOs are deeply interested in knowing whether they can sell their products to U.S. government agencies. When they ask, we try to give as definitive an answer as we can: Yes, no and maybe.

Read more

What Merlin Ventures looks for in startups

There’s no doubt that 2021 has seen record-setting attacks, including last week’s announcement about an Atlassian Confluence vulnerability being exploited in the wild. Driven in part by the geopolitical climate, cyberattacks against U.S. federal, state, and local governments are growing in frequency, sophistication, and boldness. Between high-profile attacks such as the SolarWinds and Kaseya breaches and a shift to cloud computing that has rendered traditional perimeter security obsolete, government agencies are facing an increasingly urgent need to prioritize security.

Read more