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

Why we created Merlin Ventures

There are 607 venture capital firms operating in Israel. (Trust us. We had our poor analyst count them.) Of those, 146 do cyber investments. So clearly what Israel, and the world at large, needs now is pretty much anything other than one more cyber-focused VC.

Read more

Amazon Web Services acquires Merlin Ventures portfolio partner Wickr

Amazon Web Services announced today that they have acquired Wickr, the IT industry’s most secure, end-to-end encrypted, communication platform. The 10-year-old company has grown rapidly and has been a Merlin Ventures portfolio partner since 2019. Merlin congratulates Wickr on this exciting next step in its evolution!

Read more