Research

We are big on Quick Wins at Securosis. Mostly because we know how hard it is to justify new technology (or processes or people), and that if you can’t show value quickly on a new project, every subsequent request gets harder and harder to get through. Until you have a breach, that is. Then your successor gets carte blanche for a honeymoon period to do the stuff you were trying to do the whole time. Ultimately disrupting a phishing attack is an application simple economics. If it costs more for attackers to phish your brand, their margins will go down and eventually they will look to other attacks (or other targets) that return more profit. So for Quick Wins, focus on making phishing campaigns more expensive. That means messing with their sites, more effectively helping customers protect themselves, and ultimately shortening the window attackers have to monetize your customers. Your quiver is filled with the key intelligence sources we discussed in Analyzing the Phish Food Chain, so what comes next? How can you use information like phisher email addresses, IPs, and domains to disrupt and/or stop attacks on your brand? Taking the Phish out of the Pool The first and most common remediation remains the phishing site takedown. Obviously phishing attacks are frustrated if the evil site is not available to harvest account credentials and/or deliver malware. But this is not an immediate fix – it takes time to prepare the documentation ISPs need, domain registrars, domain owners, browser vendors, telecom providers, and any other organization that can take the site offline. But remember that many phishing sites are hosted on legitimate – albeit compromised – web sites, so site takedowns inflict collateral damage on legitimate sites as well. We are not in the excuses business, so it’s not like we would feel bad when a compromised site is taken down until fixed, but keep in mind that the cost isn’t only to the phisher. One of the keys to dealing with advanced malware is determining whether it makes more sense to observe the attacker to gain intelligence about tactics, objectives, etc., than to remediate the device immediately. Phishing sites demand a similar decision. If you have identified the phisher as a frequent attacker, does it make more sense to observe traffic from those sites? Or to monitor the attack kits and analyze the malware downloaded to compromised devices? The answer varies, but this kind of analysis requires sophisticated incident response and malware analysis capabilities. A few other tactics can be helpful in disrupting phishing attacks, including directly notifying browser vendors of malicious sites because all major browsers now include real-time checks for phishing and other malware sites, and warn users from visiting compromised sites. Similarly, communicating with the major security vendors and submitting IP addresses and domains to their security & threat research teams, can give these sites and IPs negative reputations and block them within web and email security gateways. If you have been able to identify the email address the phisher uses to harvest account credentials, you can work with their service provider (typically a major consumer email provider such as Google, Yahoo!, or Microsoft) to limit access to the account. Or work with law enforcement to track the attacker’s identity as they access the account to collect their spoils. All these tactics make it harder for phishers to lure victims to their phishing sites, steal information, and then harvest it. Speaking of law enforcement, much of the information you need to gather to facilitate phishing site takedowns, such as IP addresses, domains, email addresses, and phishing kit specifics, is directly useful for law enforcement’s ultimate efforts to prosecute the phishers. Prosecution is rarely job #1, especially because many attackers reside in place where prosecution remains difficult, but if you need to gather the data anyway, you might as well let law enforcement run with it. Other Tactics for Disrupting Phishing Taking down the phishing site isn’t your only means to disrupt attacks. You can also use active controls already in place in your environment to minimize the damage caused by the attack. Let’s start with the network: your intelligence efforts have yielded a number of data points, such as IP addresses and domains associated with an attack. You may be able to work with the network operations team to block devices connecting to your site from these IPs or domains. At least you should be able to tag these devices and monitor their transactions for suspicious activity. When dealing with fraud attacks against millions of customers, being able to focus your efforts on accounts more likely to be compromised really helps. Another tactic is to adaptively require stronger authentication for accounts exhibiting suspicious activity. Phishers collect account numbers and passwords, rarely worrying about security questions or additional authentication factors. So if you see a login attempt from a suspicious IP address or domain, you can further challenge the user attempting to login by requiring additional authentication details. Attackers generally attack the easiest targets, so this is a great way to make attacks against you more expensive, and is likely to drive phishers elsewhere. Finally, you can work harder to stop the original phishing emails from reaching your customer’s inboxes in the first place. Leverage new standards like DMARC, which enables service providers and other large-scale senders to leverage DKIM and/or SPF message authentication technologies to provide more accurate sender authentication. Combined with traditional anti-spam analysis techniques, these technologies can minimize false positives and ensure phishing messages get tossed before customers get an opportunity to hurt themselves. Addressing the Root Cause Ultimately, much of what you can do to disrupt phishing is reactive. But it may also make sense to try reducing the likelihood of compromise at the point of attack: your customer. You can start with security education, working to help customers identify phishing domains and recognize the security mechanisms most consumer brands apply to email they send to customers. We are painfully familiar with the frustration of security awareness training, but

The Nibble security blog had a very good post on Subverting a Cloud-based Infrastructure with XSS and BEEF. They essentially constructed an XSS attack to issue network infrastructure management commands without user knowledge. The idea is pretty neat: all network devices and security appliances (wired and wireless) can be managed by a cutting-edge web interface hosted in the cloud, allowing Meraki networks to be completely set up and controlled through the Internet. Many enterprises, universities and numerous other businesses are already using this technology. As usual, new technologies introduce opportunities and risks. In such environments, even a simple Cross-Site Scripting or a Cross-Site Request Forgery vulnerability can affect the overall security of the managed networks. There are two important takeaways here, so don’t get caught up with a specific vendor’s vulnerabilities or the specific tool used to craft this attack. The management interfaces for all cloud services are browser-accessible, and browsers – and the web services they use – are open to these attacks. XSS and CSRF are major issues, and we have considerable evidence – the Mandiant report being just one source – that browser-based attacks are one of the top two current attack vectors. These are problems that most organizations don’t consider when building web applications, so they are common vulnerabilities. Which leads directly into the second issue: that all cloud services, by definition, offer broad network access. That means applications and management interfaces are both browser accessible. The beauty of cloud services for IT management is that you can access all cloud management functions from any browser, anywhere. And from that single connection you do just about anything. Very convenient! For attackers too – once they compromise a customer’s management plane for a cloud service, that is equivalent to root access. Only in this case it’s the entire cloud infrastructure, not just one server. Because the attack originates from your browser, it does not matter whether you restricted management access to in-house IP addresses – your system has one of the approved IP addresses. There are not many quick and easy ways to protect against this type of attack, but use a dedicated browser for management if you can. Other than that … be careful what you surf for. Share:

I was perplexed by the wording of many initial reports on the recent attacks ‘against’ Apple, Facebook, Twitter, and Microsoft. Sure, maybe they were targeted, but it seems just as likely that the attackers just picked popular developer sites and harvested some big fish. That is the essence of a a good piece at securityledger: Rather, the wide net of watering hole web sites pulled in employees from organizations across a broad swath of the U.S. economy, say those with knowledge of the incident. That has made the operation look more like a fishing expedition than a narrowly focused operation.   Developers are typically soft targets, with extensive access to internal resources. In this case I would bet that most Mac-based developers have Java enabled in their browsers. As a former dev myself, they spend a lot of time in various fora with crappy security and which are thus prone to compromise. I still spend a lot of time on those sites, but I am probably more careful than most devs or admins. Developers and administrators are in jobs that require deep access to sensitive resources, more control over their own systems, and a larger software attack surface (Java is essential for managing certain systems and platforms); but they aren’t necessarily more secure than average users, beyond basic attacks. Targeting job roles rather than organizations seems like a good strategy. Hit something popular enough within the development or admin communities, and the odds are very good that you will gain access to a variety of prime targets. No one works in a vacuum. Image: a real watering hole, with a croc you can’t see. Took this one myself in Africa. He/she wasn’t hungry that day. Share:

As we discussed in Industrial Phishing Tactics, phishing is a precursor to many attacks in the wild. Phishing attacks are designed to get victims to click something, then to share the victim’s account credentials and download malware; and of course they leave a trail like everything else. Following that trail can help you prioritize remediation activities, identify adversaries, and ultimately take action to protect both your environment and your customers. But first you must be able to analyze the email to identify the patterns to look for. And that requires a lot of email – a whole lot. Sampling all the phish in the sea Email-based threat intelligence entails analyzing scads of spam emails using Big Data Analytics. You didn’t think we’d be able to resist that buzzword, did you? Of course not! But whether you call it big data or just “a lot of data,” the first step in implementing an email-based threat intelligence program is to aggregate as much email as you can. Which brings up a reasonable question: where do you get that kind of email? If you are a private enterprise it can be hard. There are various spam archives available on the Internet (Google is your friend), but not many fresh ones. Alternatively, you could establish partnerships with email service providers, who tend to have millions of blocked emails from internal spam filters lying around. Another source would be other consumer brands – perhaps some of them would be willing to swap. You give them a copy your spam mailbox in exchange for theirs. Besides the email addresses, there isn’t likely to be sensitive data in obvious spam, so this shouldn’t trip the general security aversion to sharing data. But you will likely need an intelligence feed from a third-party analysis provider. As discussed in both the Early Warning System and Network-based Threat Intelligence (NBTI) research, we see a market emerging for intelligence providers specializing in aggregating and analyzing these data sources. They provide intelligence that can be used by enterprises to shorten the window between attack and detection. Let’s dig into the kinds of intelligence we are looking for in phishing emails, and get back to the metaphor we introduced in the NBTI paper: the Who, What, Where, and When of phishing. Who? Establishing the ‘who’ behind phishing is probably the most important intelligence you can receive. Because a select few highly effective phishers (hundreds, not thousands) are behind many of the attacks you will see in the wild. So the ability to identify the author of attacks can yield all sorts of information, enabling you to profile and analyze your adversaries. Why is adversary analysis important? Motive: Is the phish part of a targeted attack (spear phishing)? Is it part of a widespread attack on a financial institution to harvest account information? Is it to steal intellectual property? Knowing your adversary allows you to determine his/her motives, and thus to more effectively judge the true threat of the attack to your organization. Tactics: Does this phisher use malware extensively? Do they just harvest account information? Is key logging their main technique? Understanding and profiling the adversary can indicate which controls to be implement to ensure protection. Also keep in mind that the ultimate target of the phishing attack is usually your customers, rather than your employees. So this helps you decide whether helping customers protect themselves is a worthwhile expense for you. Capabilities: Finally, isolating your adversary and tracking them over time (as discussed below) provides clues to their capabilities. Do they rely purely on commercial phishing kits? Are they able to package 0-day attacks? Is it something in the middle? The more you know about the attackers, the more effectively you can make decisions about how to react. The ultimate objective of adversary analysis is to more effectively prioritize remediation activities. Knowing who you are dealing with and what they are capable of is key, and can help you determine the urgency of response. What? So how do you find a specific attacker within a corpus of millions of spam and phishing messages? It all comes back to profiles. The links embedded in the phishing messages indicate the locations of phishing sites, and you will see patterns in the domains and IP addresses used in attacks. Working backwards you can analyze the phishing site to determine the attack(s) in use, the tactics and capabilities used, and if you get lucky perhaps the attacker’s identity. This next level of analysis involves looking at ‘what’ the attack does. A key development that made phishing far more accessible to unsophisticated attackers was phishing attack kits. These kits provide everything an attacker needs to launch a phishing campaign – including images, email copy, and specific tactics to capture account credentials. Of course phishing messages still need to evade an organization’s spam filters, but that tends to be reasonably straightforward given that phishing messages should look exactly like legitimate messages. That takes most of the sophisticated content analysis done by anti-spam filters out of play. But these kits leave a trail, in the form of the source code used to install the kit on a compromised server. If you get an actual phishing kit you can analyze it just like any other malware (as discussed ad nauseum in Malware Analysis Quant) for clues to the malware used and what is ultimately done with stolen account credentials – all of which can help identify the attacker’s email. Even better, profiling attack kits enables you to look for similar attack profiles, to identify the attacker far more quickly next time. Given a sufficient corpus of spam and phishing messages, you can mine the data for patterns of IP addresses and domains, to help identify the adversary and assist in identifying appropriate remediations. Where? As described above, phishing messages look like legitimate email, so much of anti-spam filters’ content analysis cannot detect them. But you can (and need to) analyze email headers to figure out where the messages come from, the path they take to your gateway, and for clues in links to phishing sites. That brings

In the immortal words of Jay-Z, you’ve got 99 problems but BYOD ain’t one of them. Colin Steele does a good job of putting the BYOD (and broader mobility) situation in proper context in You can’t solve BYOD because it’s not a problem Not a week goes by that I don’t receive a press release or read a news article about some new product or other that “solves BYOD.” Vendors and customers that look at BYOD as a problem to solve, and not an opportunity to take advantage of, are missing the point. There is a lot of truth in that statement. It’s a technology version of “Vendors are from Mars, Customers are from Venus.” Customers want to bitch and vent about things, so vendors think that means they need to solve the problem. Mobility is something all organizations need to deal with, but it’s not something you can ‘fix’ by installing an agent or bolting an appliance into a rack. BYOD is disruptive. It brings challenges. It takes control out of IT’s hands. But these issues are simply the natural fallout from IT’s inability to keep up with users’ technology needs. That is the problem that needs to be solved. Let me highlight the money quote there. “…the natural fallout from IT’s inability to keep up with users’ technology needs.” Yup. But security folks know how this movie ends much better than most other technology disciplines. Employees do what they feel they need to do, whether you like it or not. They will get around your controls. They will skirt your policies. And they will get their jobs done. Of course we don’t advocate a wild west, “do whatever the hell you want,” approach. But it is essential to place mobility in its proper context, which means an acceptance that it is happening. So get on board and work collaboratively with the right folks to apply some reasonable control. Or get run over… Photo credit: “No problems” originally uploaded by Gamma Man Share:

Shiny technology objects make us happy. Admit it – you want to believe the buzzword du jour will make things better. Or less crappy. But if the capabilities and value of new technology are contingent on humans, eventually you run into the most debilitating of constraints: expertise limitations. It seems like everyone wants to talk about Big Data Analytics, but the inconvenient truth is that without the math folks Big Data doesn’t do much. As the WSJ writes, Data Crunchers Now the Cool Kids on Campus: The explosive growth in data available to businesses and researchers has brought a surge in demand for people able to interpret and apply the vast new swaths of information, from the analysis of high-resolution medical images to improving the results of Internet search engines. Schools have rushed to keep pace, offering college-level courses to high-school students, while colleges are teaching intro stats in packed lecture halls and expanding statistics departments when the budget allows. So we see the problem, and now the education/industry complex is moving to address the skills gap. Good luck with that. Math is hard. Sure, it may provide a wonderful career path, but it’s not like all those liberal artsy types who don’t see much of a future as lawyers will all suddenly decide statistics is their calling. I do believe in the eventual impact of Big Data Analytics on all sorts of things including security. But we need to be realistic as an industry about when that impact will actually materialize. The rich can (and will) get richer by throwing money at math PhD’s, but the rest of the world will lag significantly. But we will be hear a lot of the term Data Scientist over the next few years. I’m lucky that my kids seem to be pretty mathematically inclined, so over time I will push and prod them toward statistics. Though by then there will be another shiny object to chase. There always is. Share:

Threat Intelligence comes in many shapes and sizes, all of which are helpful for Early Warning of imminent attack. After introducing the initial Early Warning concepts, we recently delved into how network telemetry and other information about your pipes can help to identify compromised devices in Network-based Threat Intelligence. We continue discussing all sorts of threat intel by focusing on phishing in our new series, Email-based Threat Intelligence. We stay true to our naming conventions. But in all seriousness, if you are targeted by phishing attacks, you probably know what we’re talking about. Attackers target your brand, they stage high-volume attacks to steal personal information from customers, and then ultimately they monetize stolen personal data – typically by looting the accounts of your customers. All of which cost your organization big money. So what we will do in this series is dig into the seedy underbelly of the phishing trade, starting with an explanation of how large-scale phishers operate. Then we’ll jump into threat intelligence on phishing – basically determining what kind of trail phishers leave – which gives us data to pump into the Early Warning system. Finally we will cover how to get quick wins with email-based threat intelligence. If you can stop an attack, go after the attackers, and ultimately disrupt attempts to steal personal data, you’d do that, right? So we will wrap up this short series by quickly showing impact. Before we get started I want to thank Malcovery for agreeing to potentially license the content at the end of the project. As with all our research, we will produce Email-based Threat Intelligence using Totally Transparent Research. That means we build the content independently and objectively, and tell you what you need to hear. Not what any vendor wants you to hear. Sizing up Targets Why do phishers target specific brands? To harvest and ultimately monetize personal information. Obviously targeting financial institutions is a no-brainer. So you probably see phishing attempts targeting every major bank, brokerage, and other financial institution like PayPal fly into your inbox all the time. Retailers are also low-hanging fruit – once phishers gain access to an online shopping account they can buy all sorts of stuff using your customer’s credit. And you get left holding the bag. Fun! But lately we have been receiving phishing attempts for other major consumer brands such as shipping companies, phone companies, and airlines. Huh? If someone owns a frequent flyer account, the risk is having them see how close until the next FF tier, right? No, not exactly. When you (or someone who works for your organization) clicks on a phish, they may enter account information into the phishing site, which is the first win for the attacker. But it’s not the only opportunity for pwnage. Attackers also systematically install malware on the device, and that’s where the real monetization happens. Once they have a foothold they mine the data for as long as they can. Attackers collect bank accounts, passwords, and other sensitive information. So basically every large consumer brand has been and will continue to be a serious phishing target. These companies have millions of customers, which means millions of potentially compromised devices for attackers to mine. Obviously the highest value phishing attacks target financials, where the victim can be monetized immediately. But the endgame involves installing malware which is why we see secondary brands emerge as phishing targets. It is outside of the scope of this research, but we would be negligent if we didn’t at least mention that it’s a very bad idea to save financial information in the website of any retailer or other services company. Sure, one-click buying is convenient, as is not enter that pesky credit card number with every purchase. But it also leaves you at the mercy of the website’s security – not a good place to be. If you do need to save personal information on these sites, at least use very strong unique passwords with a password manager, as Rich has described numerous times in places like MacWorld. The Phish Phishing is the front end of a multi-faceted attack, so let’s take a look at the first set of steps in Cloppert’s Kill Chain and show how these concepts apply to phishing. First let’s look at recon, which starts with picking the brand to target, typically a financial or payment company. The APWG’s statistics (PDF) show that upwards of 65% of phishing targets are financial and payment organizations. Duh. But let’s be clear about why many of the phishing campaigns target only a few popular brands. Is this just Pareto at work? The real reason is the advent of the phishing kit. Just like malware kits, phishing kits offer a packaged phishing campaign for a very modest price. This takes care of the weaponization step in the kill chain – these kits include everything you need to phish, with the exception of domains to host the phishing site. Images, emails, designs, and even a few malware variants are included, which is driving down the average IQ of phishers. You might think phishing kits need to be constantly updated to keep pace with the constant web site changes undertaken by the major consumer brands. Not so much – most consumer victims wouldn’t be able to tell a vintage 2009 Wells Fargo site from the latest and greatest. The images and code used on the phishing site tell a story about the attacker and can provide significant intelligence to disrupt the attack, so we will delve into that in the next post. The other key aspect of the kill chain for to phishing is delivery. The primary delivery mechanism for phishing is email, which requires the attacker to evade spam filters. Discussing those tactics is a bit beyond what we can do in this series, but suffice it to say that attackers are rather sophisticated in how they test both delivery of email and the domain names they drive victims to. Similarly to the way attackers use VirusTotal and other AV test harnesses, phishing professionals focus quite a bit of effort on testing against common anti-spam engines,

Thales released a 2012 survey on encryption spending trends today. In a nutshell, spending was up a modest amount for the first time in several years. From the Deep Dive post: estimated total spending on encryption by all sectors grew by 2.5 percent from 2011 to 2012, one of the biggest jumps in the eight years the survey has been conducted. Thales released the “2012 Global Encryption Trends Study” today. The Ponemon Institute of Traverse City, Mich., surveyed 4,205 individuals on Thales’ behalf. The spending figures were particularly interesting to Thales: “This last year we saw one of the biggest hikes in budgets that we’ve seen for the last seven years or so,” said Thales e-Security’s Richard Moulds, vice president of product strategy. In 2011, businesses and governments spent 15.1 percent of their information technology security budget on encryption. The number jumped to 17.6 in 2012. A couple things to note about this information. For security products not driven by compliance (like PCI) or vulnerabilities that totally disrupt IT (think SQL Slammer), sales typically grow at a rate of 2-3% a year. From our conversations with companies of all sizes, use of encryption is up across the board. However, adoption is mostly for new projects, rather than expansion of existing installations. And in many cases developers are the ones who select free or open source encryption products, not commercial products. They do this so the development process is not burdened by having to get budget or deal with sales droids. This means spending does not go up at the same rate that usage goes up. Still, the encryption market has not seen the sales growth we would otherwise expect – instead people invest in better key management services, or in alternatives to encryption (e.g. tokenization, masking) to protect data. It’s a growing market, but buyers are cautious about how and where they spend their money. Share:

One trend we see coming on like a freight train is the rebirth of security awareness training. Folks are working on content that doesn’t suck and enterprises are finally starting to gather data about how stupid mistakes (such as clicking phishing messages) are decreasing after training sessions. NetworkWorld recently ran an article (in their Insider section, which requires registration – boo!) providing some tips to deal with phishing. The part of the article I found most interesting was a description of how attackers appeal to either greed or fear to entice action. It sounds a bit like marketing to me… “most spear phishing attacks take one of two tacks – they either appeal to human greed or fear. In other words, either they offer money, coupons, discounts or bargains that are too good to be true. Or they announce that your checking account or eBay account has been frozen and you need to re-enter your credentials, or some other scenario in which you are required to enter personal information….or else.” Then there are a few tips about educating users, including having them look at URLs from right to left. Folks who read Hebrew have a clear advantage at this. And other obvious stuff, including not opening files from folks you don’t know, and never providing account credentials to an unsolicited query. Of course all this seems obvious to you and me. It’s too bad it’s not obvious to your employees. Get on board with security awareness training. Or keep cleaning up the mess. Photo credit: “Clean Up or You’re Out! :Brooklyn Street Sign” originally uploaded by emilydickinsonridesabmx Share:

With our last post in this series on Understanding and Selecting Cloud Identity and Access Management, we want to help guide you through product selection. No two customer environments or lists of requirements are the same, but key decision criteria will help you narrow down the field to suitable platforms. We will provide questions to help determine which vendors offer solutions that fit your architecture, a set of criteria to measure the appropriateness of a vendor solution to your design goals, and help walk you through the evaluation process. Your mileage WILL vary Spoiler alert – there’s no such thing as plain vanilla IAM. You may need a solution for customers as well as users. You may or may not need to include mobile devices. You may need fine-grained authorization controls for external applications. There are far too many variables in play for IAM evaluation to be fully quantifiable. But to help you weed out some players, to align your needs with product function, and to give you a handle on major product differentiators, we created the table below. You need to make sure products match your goals. Even IAM suites that can do everything on paper have their own strengths and weaknesses, so make sure you know them before leaping in. As we have discussed, prospective buyers should start with understanding their use cases and governance processes before analyzing the IAM marketplace. That said, here is a proposed checklist for beginning to analyze IAM products: Product Architecture What are the product’s key capabilities? What are the internal data models and formats for identity? What are the external data models and formats for identity? How does the product scale, vertically or horizontally? Development What is the development interface for implementing and extending the product? Is development typically performed by the company or third party consultants? Answer for both development and maintenance phases. What integration is available for source code and configuration management? What languages and tools are required to extend the product by with wrappers, adapters, and extensions? Interoperability What IAM standards are supported and where are they available in the product? What interfaces are standards based and what are proprietary? What directories are supported – Active Directory, LDAP …? What application servers are supported – Websphere, IIS, Tomcat, SAP …? Are cloud applications supported? Which ones? Are mobile platforms supported? Which ones? Product Security What is the product security model? Is Role-Based Access Control supported? Where? How is access audited? Use Case Support Describe the product’s support for provisioning uses Describe the product’s support for Singe Sign On uses Describe the product’s support for attribute exchange use cases What user self-service capabilities does the product support? Cost Model How is the product licensed? Does cost scale based on number of users, number of servers, or something else? What is the charge for adapters and extensions? This checklist provides a starting point for analyzing IAM products. As the evaluation unfolds, it is key to remember what matters: integration, standards, and cost. The buying process works much better if the initial step includes an inventory of IAM sources and targets: where identity is used, and what the authoritative sources are. What IAM processes exist currently, and which and are desired in future? POC FTW Securosis highly recommends a Proof-of-Concept (POC) as a final step for IAM buyers. PowerPoint does not crash much, but new implementations do. There is nothing like seeing a product working in your own environment. If there is more than one vendor in play – and there usually is – then bake-offs can be useful to determine the best fit. But we generally do not recommend bake-offs with more than two vendors. Many vendors take widely different conceptual approaches to IAM problems, and in-depth evaluations are too demanding to perform more than once or twice. Start with an initial review, against our checklist, to weed out unsuitable candidates. Then use a proof of concept to test viability and/or a bake-off to compare a couple similar candidates. Share: