Blog – Page 2 – Merlin VC

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

November 17, 2021/in Blog/by Website Administrator

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?

October 25, 2021/in Blog/by Website Administrator

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?

September 24, 2021/in Blog/by Website Administrator

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.

What Merlin Ventures looks for in startups

September 9, 2021/in Blog All Companies/by Website Administrator

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.

Why we created Merlin Ventures

August 24, 2021/in Blog/by Website Administrator

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.

Amazon Web Services acquires Merlin Ventures portfolio partner Wickr

June 25, 2021/in Blog/by Website Administrator

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!

Why fly when you can SOAR? 5 things you’re getting wrong about security orchestration, automation and response

August 28, 2020/in Blog Swimlane/by Website Administrator

Security orchestration, automation, and response (SOAR) solutions are often billed as a panacea that will solve all of a security operations center’s (SOC) problems, reduce mean time to repair (MTTR), improve efficiency, act as a single pane of glass, and even make a really good cup of coffee. You name it and someone somewhere has claimed that a SOAR platform can do it. The truth, however, is a little more complicated.

Yes, a SOAR solution can automate a great number of tasks—if properly implemented. If a task can be broken down into steps that are repeatable, reusable, and consistent, then it has the potential to be automated. But if an organization tries to take on too much at once or is unfocused in its approach, the implementation can rapidly get out of hand and lead to failure and ultimately shelfware. Here are a few examples of common mistakes and misconceptions about SOARs.

Boiling the ocean

A SOAR solution can be incredibly powerful; the initial desire to automate everything in sight is akin to the first time you get a label maker. You want to apply it to everything, all at once. Some of the worst experiences I’ve seen have come from an environment where they tried to build a complex interweave of use cases and became bogged down in the details and frustrations. The key to a successful implementation is to start small. Find one or two simple use cases that allow the SOC team to get a handle on what can be done and the thought process to build the use case. Initial simple automations and response actions such as threat enrichment of an IOC (indicator of compromise), hash, or URL are particularly effective as they can be easily reused as part of more complex actions later.

Training? I don’t need any stinkin’ training!

Yes, you do. While this is often the first thing on the cutting room floor when budgeting for a new solution, training usually makes the difference between a successful implementation and a package becoming shelfware. This is the opportunity for your team to ask questions of the people who implement and use the technology daily. Take advantage of it. A SOAR platform, like most integration-focused solutions, has many hidden features and nuances to how complex actions like a workflow are created. These are going to be automated actions that are hopefully going to run your business and you’ll need to understand how they are constructed.

I have scripts, isn’t that the same thing?

Most engineers, analysts, or administrators who have worked in IT for more than a few years have ended up running into tasks that they find themselves doing repeatedly. Inevitably, someone on the team will write a script, whether it is Visual Basic, a batch file, or a snippet of Java for each of those routine tasks. Those scripts are running continually in SOC near you right now. So, the question becomes: If I’ve already got scripts running, why do I need a SOAR? Remember, SOAR stands for security orchestration, automation, and response. Automation refers to performing singular tasks repeatedly, orchestration is putting multiple singular tasks together, and response is really the key because it’s the ability to evaluate, make a choice, and then perform additional actions. The ability to build-in complex response actions, either in an automated fashion or via human interaction, is one of the primary differentiators of a good SOAR platform. This doesn’t mean throwing the scripts out, it means taking them and converting them into SOAR workflows that can provide response choices, in-depth auditing and error tracking, and consistent integration across multiple platforms. This is where SOAR sets itself apart.

It will be done tomorrow right?

Not likely. While an initial set of use cases or workflows can usually be imported from the SOAR vendor, they still need to be customized to your environment. For instance, it may have been written for a different firewall or threat feed vendor. Each of these steps will need to be verified and tested with the current version of the existing platforms deployed in the environment. A simple version difference in the target platform can make a huge difference. Which brings us to…

Integrations are simple

Umm, no. To be successful, a SOAR platform will need to communicate with many different platforms that already exist in your environment. Let’s face it, the IT space is full of companies that are often competing with one another in multiple verticals and one vendor is rarely sole-sourced throughout the organization. It’s not uncommon to see vendors significantly change APIs, database structure, architecture, and platforms in between versions with either missing or incorrect documentation to go with it. These changes are not made to purposefully break outside integrations but are instead made with their own interests in mind. Simply put, IT infrastructures are complex environments with lots of moving parts that need to be carefully integrated to get the best value from the solutions. Often the response from vendors’ support teams will boil down to “not my problem.” Ultimately, a good SOAR vendor will try and keep up with the integrations as new versions are released, but some of this will also come back to a good relationship between you and your vendor. Simply letting them know that a new version released and that you intend to upgrade soon can change the integration team’s process to better support you.

Things to keep in mind

So, what are the main takeaways? SOAR solutions can be incredibly powerful enablers of the cyber and operations teams if some simple rules are followed:

Stay focused. Choose a singular task to learn what works in your organization. Use this as your inhouse training scenario to learn the process.
Take your time. Diagram the workflow on a whiteboard and take your time finding the lowest common denominator to help pick one or two use cases to leverage as your showcase.
Identify simple integrations. Choose the deployed solutions that can be easily integrated to start with. Typically, they will be API driven and allow you to combine with threat enrichment to see immediate benefits.
Re-use. Ideally, your SOAR platform allows you to reuse the work you’ve already done. You’ve created the first piece of the puzzle for the future and you can leverage that same structure and concept again to reduce the amount of effort on your next workflow.

Merlin Cyber has partnered with Swimlane to help our public-sector customers avoid these and many other challenges that they encounter. Swimlane provides a comprehensive SOAR platform leveraging a drag-and-drop workflow builder that enables organizations to rapidly build and deploy workflows to the field. With built-in case management, auditing, reporting, and a robust integration library, Swimlane provides environments with the tools they need to be successful.

If your organization wants to rapidly improve staff efficiency and drastically decrease MTTR by leveraging a powerful SOAR platform, we can demo Swimlane and help customize a solution that meets your objectives.