DEV Community: Cossack Labs

AWS security audit guide

Cossack Labs — Mon, 06 Nov 2023 11:46:20 +0000

Auditing AWS security configuration is essential for timely identifying and addressing security vulnerabilities in your cloud infrastructure and services. Sounds simple, though there are milestones to cover and security pitfalls to avoid on the way to a secure cloud environment. This is actually what we are going to briefly discuss in this post.

Cloud customers are responsible for the configurations of security controls, access management, security of their applications, and data. Read more about Gaps in the Shared Responsibility Model.

When conducting an audit of AWS resources, ensuring proper access is vital, as access levels vary depending on the infrastructure being assessed.

Key policies to consider: SecurityAudit and ReadOnlyAccess, each offering different permissions for services and metadata. The ReadOnlyAccess policy is essential when utilising automated audit tools. Attach the ReadOnlyAccess and SecurityAudit policies to the user, group, or role involved in the audit. If you run into a "403 Access Denied" when trying to use an API, it means that you don't have permission. So contact your administrator to get it.

Pay close attention to the following cloud testing components. These are important for AWS security assessments to identify vulnerabilities and risks and ensure compliance.

Identity and Access Management: Verifying that users are assigned the appropriate roles and permissions.
Compute and Container Security: Potential risks to container components, including infrastructure, applications, and other elements, are identified and assessed.
Data Protection in Transit and at Rest: Data security is evaluated when it is transmitted between systems or stored.
Secure Remote and Administrative Access: Ensuring that resource access systems are secure and effectively guard against unauthorised access.
Audit Log and Real-time Security Monitoring: During this phase, it is verified that security events are being recorded and tracked, the Ops team has access to the logs, and monitoring systems are operating effectively.
Attack Detection and Response Mechanisms: Checking if there are effective systems for detecting potential attacks and responding to them.
Security Backups and Disaster Recovery Plan: Ensuring that backups are created and stored securely, disaster recovery plans are adequate and ready for use.
Compliance with Regulatory Requirements: Checking regulatory compliance for confidentiality and other regulatory demands.

CIS Benchmarks

💡 CIS Benchmarks, created by the Center for Internet Security — globally recognized best practices for cybersecurity. CIS Benchmarks meet NIST, HIPAA, PCI CSS, and CIS standards, with three levels of protection: Basic, higher security for sensitive data, and specifically for US government requirements.

CIS Benchmarks consist of four documents for auditing AWS security:

Amazon Web Services Foundations;
Amazon Web Services Three-tier Web;
AWS End User Compute Services;
AWS Compute Services.

Each of the documents listed above has audit checklists → CIS Benchmark AWS.

Cloud Conformity Knowledge Base

To ensure the security of your AWS services, follow the best practices at Cloud Conformity Knowledge Base.

The Cloud Conformity Knowledge Base for AWS contains curated rules and recommendations for optimising AWS security, reliability, performance, compliance, and cost-efficiency.

Tools

To save your time and perform the check effectively, use the following tools to automate the process:

Awsenum / aws_recon: Tools for reconnaissance/inventory of AWS services and resources.
Pacu: An AWS exploitation framework for offensive security testing in cloud environments.
Cloudsploit: An automated tool for monitoring and auditing AWS configuration security.
Prowler: A security auditing tool for AWS used to check existing configurations against security standards such as the CIS Amazon Web Services Foundations Benchmark.
Scoutsuite: A security auditing tool that provides visual reports on the security state of your AWS environment, identifying incorrect configurations and potential risks.

AWS security is about ensuring that users can safely take full advantage of the cloud and that their data is protected from unauthorised access, loss, and theft. “Reliability” and “security” are the keywords here. A comprehensive audit of your AWS infrastructure, as well as timely identification of potential vulnerabilities, are vital to creating a secure cloud environment and protecting sensitive data.

Building security for digital wallets and financial applications

Cossack Labs — Thu, 14 Sep 2023 15:15:32 +0000

The financial market requires secure, compliant, and scalable solutions. How would you define “security”? Oftentimes it is perceived as a checklist of features to be implemented or a distraction. Others see security as a technical debt that could be taken care of “someday” when the product is already launched. But no one wants to see their product compromised and customers go. Is there a way to build a secure architecture that will serve as a shield to users’ assets and company’s name?

In this read, we’ll put on a security engineer’s shoes and walk a mile to see security from their perspective. Diving into this world will equip you with new ideas on how to build a reliable product by choosing a security-first approach.

A life-saving tip: Huge security incidents once were little weaknesses that were not timely taken care of. Thus let’s address the issues in 4+ steps:

✅ Define your unique risks and threat profile: Identify specific risks, analyse your architecture for risks that can possibly turn into threats. The next step is to develop a targeted security strategy, design and build security controls. You also need to build your incident response capability and invest in winning user trust.

✅ Fight typical risks with typical mitigations like focusing on data protection via a layered approach to security:

Platform security - the foundation of mobile / web security measures- requires special attention.
Mobile wallet security starts with OWASP MASVS and MASTG recommendations, like secure data storage, proper cryptography, local authentication, and device trust.
Web & web extension wallets are to use encrypted data storage, minimise the memory footprint of private keys and mnemonics. In the case of desktop wallets, stored private keys could be available for superusers and malicious apps.
Backend security should include secure user authentication, session handling, user enumeration, data harvesting, network settings, security headers, transaction integrity, and protection against replay attacks.
Supply chain security requires pre-selected and monitored 3rd party services.
Monitoring and incident response: Monitor transactions to timely detect anomalies and prevent potential incidents.

✅ Treat problems systematically to reduce the number of risks and vulnerabilities.

✅ Target the specific financial risks to your product and shoot back with effective tech solutions:

Key leakage and transaction fraud
User deanonymisation
Know Your Customer and Anti Money Laundering
Financial Anti Fraud Systems
Regulations and compliance

Follow the white rabbit for more juicy tips.

Building security into the development process is your key to success! Engage security engineers with product and financial expertise. Allow professionals to audit your digital wallet so that you can see the real picture and timely mitigate the risks.

When you make security the cornerstone of your product — you invest into your reputation, user retention and help your digital wallet stay competitive. As you implement smart security solutions throughout the product development process, you keep the end-user’s wants and fears in mind, doing your best to make their digital life a little easier. This is your road to success!

Read the full guide on digital wallets security.

7 Steps to Building Anti-Fraud System for Digital Wallets

Cossack Labs — Wed, 02 Aug 2023 10:01:06 +0000

The popularity of digital wallets makes them an attractive target for malicious actors. Can we develop a secure e-wallet that never pops up on the list of compromised products? According to Nelson Mandela, “It always seems impossible until it’s done”. Let’s give it a try!

The game is won by those who know the rules and how to use those to their advantage. You know what your opponent is after and what they target: The system and the user. All you need is data and proactive measures to build a strong anti-fraud system.

Use mobile apps and server-side as valuable sources of data to identify patterns, detect anomalies, and cope with vulnerabilities. Refer to proactive measures, device attestation, authentication, integrating KYC & AML, and user education to build an effective anti-fraud system. Let’s have a quick look at each of these 7 steps.

Step #1 Proactive anti-fraud measures help to manage the uncontrollable – human factor, differentiating between “normal” and “abnormal” user behaviour. We can identify suspicious/malicious users and define “stop factors” via collecting data and calculating risk scores.

Step #2 User education: allows them to protect their assets better if they know about risks and are asked for additional authentication before a transaction can be completed.

Step #3 Authenticating and re-authenticating: Choosing the appropriate user identity verification method is paramount and will depend on the specific use case.

Step #4 Integrating KYC (Know Your Customer) and AML (Anti-Money Laundering) are crucial for identity verification and fraud prevention.

Step #5 Enabling remote device attestation helps to differentiate between a legitimate and a compromised one.

Step #6 Smart balancing between usability and security allows to win users’ hearts and protect their assets at the same time.

Step #7 Working with security researchers is a promising collaboration for mitigating vulnerabilities.

For more information on building an anti-fraud system, see our informative engineering post.

Breaking and building encryption in NFC digital wallets 📳

Cossack Labs — Tue, 28 Mar 2023 21:00:56 +0000

NFC technology is now just a part of everyday life. One day, you can meet it as a developer building new firmware for an NFC device that serves as a digital wallet. Get prepared for the security challenges when using NFC.

Tap-and-go operations are used so widely and the assembly of an NFC intercepting device is so simple and inexpensive, that NFC exploits are common “in the wild”.

Crypto wallets, unmanned vehicles, access control devices, FIDO2 tokens, NFC tags, or contactless payments—NFC devices are everywhere and are often used for critical actions! And in each case, there must be proper security measures based on a threat model, as the risks may vary. But as a security-aware developer, you can reduce the chances of exploits.

We’ve seen many security problems in NFC key vaults, some of them literally migrate from project to project.

⚠️ For example, developers tend to use “encrypt-then-CRC” (Cyclic Redundancy Check) or “CRC-then-encrypt”, but both those options are unsuitable because the CRC is not designed for cryptographic integrity. The CRC is computed without secret and can be easily changed.

# CRC-then-encrypt example
# NEVER USE IT
def encrypt(key, message):
    iv = b'\x00' * 16
    tag = crc16(message)
    plaintext = tag + message
    ciphertext = aes_cbc_encrypt(key, plaintext, iv)
    return ciphertext

⚠️ Instead of crafting your own integrity checks, prefer AEAD encryption (like AES-GCM), and use a proper MAC, like HMAC, GMAC, or Poly1305.

And this is not a rare thing. Just check other problems NFC devices can bring: replay, passive MITM, timing attacks, encryption flaws, buffer overflow, etc.

💡 Well, so how to mitigate the NFC security risks? First, consider proper threat modelling and suitable secure architecture. Then implement proper security controls. Talk to cryptographers if your system involves encryption (as it should!). And, for sure, do not ignore testing, auditing, and reacting on incident stages.

Click on the image to read in-depth:

Smart contracts: audit ‘em all like a security engineer

Cossack Labs — Wed, 14 Dec 2022 18:51:40 +0000

Don’t let reentrancy and front-running attacks, signature replay, gas issues, sensitive data leakage, deadlocks, and various kinds of vulnerabilities in smart contracts pfaff you around.

⚠️ Blockchain systems are often taken as safe and secure by default. But oops they are not until someone takes proper care of their security. 🤌 Do you know that smart contracts, which are code stored on a blockchain, can be abused and misused just like other software?

In our new engineering blog post 👉 Smart contract security audit: tips & tricks 👈, we’ve gathered tips & tricks that will help you eliminate risks and threats and happily survive in this wild wild west.

🎯 The first step is a security audit.

💡 Security audit of smart contracts differs from auditing "traditional software". We’ve spent years building, auditing, and improving security / cryptography within cryptocurrency fundamental protocols, nodes, wallets (must check 👉 Crypto wallets security as seen by security engineers 👈), and bridges, so we have lots to tell about it ;)

To cover what you need to secure the smart contract’s code, infrastructure, and data flow, we’ve focused on the Tezos network and 👉 freshly-baked audit of the Tezos Project in Allbridge Classic 👈.🐬 Dive in!

Smart contracts have a lot in common with distributed applications but differ in details. They are generally small and easier to review. They have unique threat vectors, like malicious bakers or gas exhaust. They don’t store any private data but they still operate with sensitive information: signatures, administrator addresses, user balances, etc. Check them out!

How to encrypt data easily when your apps and databases are already running

Cossack Labs — Tue, 20 Sep 2022 18:11:57 +0000

What if you’ve built your app and now think about encrypting sensitive fields that it sends to the database and back? 🤔 Should you just enable the “at rest encryption” checkbox, use TLS, or add an extra encryption layer into your application code?

The first and second options make sense, the third one is not for everyone. ✨ Consider implementing transparent database encryption.✨

Database encryption works for transforming readable data into a ciphertext, aiming to protect it from unauthorized parties.

💡 When speaking about transparent data encryption, which is implemented, for example, in the Acra database security suite, we mean that encryption happens neither in the database nor in the app it speaks to. But where?—In Acra proxy!

Acra works as a SQL database proxy—so, your application communicates with the database via Acra which encrypts/decrypts sensitive fields. You can customize which fields to consider sensitive (PII, financial or regulatory-specific data), as well as what actions Acra should do (encrypt, searchable encrypt, mask, tokenize, etc.).

In such a way, the database never gets access to the plaintext data or encryption keys. That saves a lot of resources on development and requires minimum effort for protecting data.

You have encrypted data, using modern strong encryption, but you don’t deal with cryptographic code. Win-win. 😊

We designed Acra just like that. It doesn’t require any change in your app code. That is extremely useful when you have your infrastructure (apps, databases) already built.

💡 Acra is available for free on GitHub, suitable for small apps:
https://github.com/cossacklabs/acra

💡 And as a paid Enterprise license for security-sensitive products:
https://cossacklabs.com/acra

But how transparent database encryption works?

If you want to get deep into detail and learn more about database wire protocols, check out our new engineering blog post 👉 Transparent data encryption for SQL databases with Acra 0.93 👈

Subscribe to a new newsletter for security-aware developers!

Cossack Labs — Mon, 22 Aug 2022 17:42:19 +0000

Hi, I’m Felix from Cossack Labs.

You might know me as a mascot of these cool data security & cryptography guys. But time flies. Code is everywhere, and nummy bugs are everywhere too.

So, meet me in a new role—as a junior security researcher bringing you a 🐝-weekly newsletter Shift Security Left, teaching how to design, build, and test secure software. 😎🤟🏻

Every two weeks, on Saturdays, I’ll drop into your inbox an email with a few links to great & awful security news, practical articles, papers, tools, and other security stuff to make your apps more secure.

The first issue is already available!

Subscribe here: Shift Security Left—and share with friends!
Follow me on Twitter: @ssl_newsletter

🚨 Robotic devices can be hijacked through cryptographic failures in encryption

Cossack Labs — Thu, 30 Jun 2022 08:03:30 +0000

You can often hear security engineers saying “do not design your cryptosystems, especially if you don’t know anything about them”. Nah, ignore it. What can really go wrong?

Imagine you have a radio-controlled 🚗💨 toy car.

It’s very popular and has an open-source firmware with a large community around. Your car uses secure protocol to communicate with remote control and can drive on a long distance.

Is it protected from the hijackers now? Well, we doubt a lot 🤔, as crypto bugs can sit in the code invisibly until it’s too late to notice them.

What can happen?

🔘 Static IV in CBC fails to achieve probabilistic encryption
🔘 AES-CBC Padding Oracle attack
🔘 AES-CTR is broken using fixed nonce
🔘 Encrypted messages integrity is not protected
🔘 Side channels and replay attacks
🙀 and that’s still not all folks.

Read our new article 👉 Cryptographic failures in RF encryption allow stealing robotic devices 👈 and play interactive demo games to learn how your robotic devices can be stolen from you by someone with a radio antenna.

Improving security & cryptography in popular cryptocurrency wallets

Cossack Labs — Wed, 08 Jun 2022 10:10:37 +0000

Lots of people apply the idea that “blockchain is secure” by default to every project that has “blockchain” in its description. But in tech, you know it’s not so simple.

From a security perspective, we often see weak points requiring special attention in cryptocurrency ecosystems and their wallets (read our blog post Crypto wallets security as seen by security engineers to 🐬 deep dive into the topic). When working with large blockchain foundations, we ensure that their ecosystem (wallets, backends, APIs, protocols) are secure.

▶️ Have a look at a real-life example.

Say, there’s a blockchain foundation with a non-custodial cryptocurrency wallet available for millions of users as mobile applications and a web extension.

The users, regulators, investors, etc. expect that the cryptocurrency wallet gives the same level of security guarantees as modern financial or banking apps.

💡 Since this is a non-custodial cryptocurrency wallet, special attention should be paid to protecting data on the client side and its communication with a blockchain.

This comes with the requests for:
✔️ advanced level of protection,
✔️ encryption for data at rest (non-custodial wallets store private keys and mnemonics),
✔️ platform-specific security controls for all the supported platforms,
✔️ building app security into UX.

▶️ Now this looks like a job for us.

So, we roll up our sleeves and, using the superpower :) of our mobile apps security, security and cryptography engineering services, and a cryptographic library Themis, we:

🎯 assess risks and do threat modelling for the apps and backend ecosystem.
🎯 conduct a deep cryptography audit of the wallet: web extension (Chrome, Firefox, Chromium) and mobile apps (iOS, Android).
🎯 provide cryptographic enhancements and dozens of application security improvements aligned with the “defense in depth” approach.
🎯 analyze the development process and advise SSDLC improvements (from further automation in CI/CD pipeline to formalizing a security roadmap).

Read the detail behind every stage in our case study Filling cryptography and security gaps in cryptocurrency wallets🐬 to learn how these efforts resulted in web extension and mobile apps synced in their security guarantees and providing defence in depth protection for the users’ data. 🔐

cossacklabs / themis

Easy to use cryptographic framework for data protection: secure messaging with forward secrecy and secure data storage. Has unified APIs across 14 platforms.

Themis provides strong, usable cryptography for busy people

General purpose cryptographic library for storage and messaging for iOS (Swift, Obj-C), Android (Java, Kotlin), React Native (iOS, Android), desktop Java, С/С++, Node.js, Python, Ruby, PHP, Go, Rust, WASM.

Perfect fit for multi-platform apps. Hides cryptographic details. Made by cryptographers for developers 🧡

What Themis is

Themis is an open-source high-level cryptographic services library for securing data during authentication, storage, messaging, network exchange, etc. Themis solves 90% of typical data protection use cases that are common for most apps.

Themis helps to build both simple and complex cryptographic features easily, quickly, and securely. Themis allows developers to focus on the main thing: developing their applications.

Use cases that Themis solves

Encrypt stored secrets in your apps and backend: API keys, session tokens, files.
Encrypt sensitive data fields before storing in database ("application-side field-level encryption").
Support searchable encryption, data tokenisation…

View on GitHub

RepoMetaScore: evaluate supply chain risks of open-source projects

Cossack Labs — Wed, 18 May 2022 17:08:27 +0000

Open-source software saves time on development but should be taken carefully, as the code is in the hands of maintainers and contributors you know nothing about.

🚩The threat of intentionally weaponizing open-source tools by criminals is growing every year. Recently, novel risks have emerged: developers living in oppressed countries are being pushed into introducing backdoors involuntarily.

⚠️ Backdoors and vulnerabilities introduced into OSS can cause ruinous aftermaths.

One of the ways to prevent them is to employ vulnerability scanners for analyzing third-parties libraries your project uses, but, unfortunately, sometimes they alert too late.

Another option entails identifying and quantifying security risks linked to third-party libraries before adding them to your product.

🔎 RepoMetaScore

To help developers avoid risks associated with weaponizing OSS, our security engineers have built a RepoMetaScore. It’s a tool that collects information about the project and its contributors, analyzes it, and calculates risk ratings by several criteria: GitHub and Twitter profiles, location, commit history, email domain, etc.

💡 Note, that RepoMetaScore (📥 GitHub) should not be used as the only tool for assessing open-source repositories’ credibility. Use it wisely as an additional tool for mitigating current threats in open source.

🔨 How RepoMetaScore works

Repometascore uses public information disclosed by contributors themselves. RepoMetaScore collects such info through the APIs and calculates results as a risk rating. It can be the first tool in a series of security checkup developers go through when deciding whether to add a certain project or not.

💡 To use RepoMetaScore, follow its Readme. It’s a simple python package that should work on any Unix and Mac.

Provide RepoMetaScore with a link to a repository-in-question—and get the risk rating results and general information about repository contributors.

Encryption in ⛅ cloud native apps

Cossack Labs — Thu, 12 May 2022 17:14:03 +0000

Devs are often tempted to leave data security “as is” while building cloud native apps. With all the options cloud providers give, you can have an illusion of everything running securely by default. But…

...In reality, the need for data protection and app security does not disappear automagically in a cloud and security requires your efforts and a different approach. You’re to protect the data whenever it exists.

🌁 But why?

In a cloud environment, you have many security concerns eliminated or cared by the cloud provider. Simultaneously, you have less control over the perimeter and many things are just checkboxes on the admin panel.

Since infrastructure capacity is no longer a limit in a cloud, you can have multiple complex dataflows – and they require setting out and mapping controls onto them.

❇️ For example, to prevent other developers and DBAs from accessing sensitive data in production you’ll need field level encryption. To stop SQL injections and insiders you’ll have to request firewalls and monitoring tools. To restore the events and find a root cause in case of incidents you’ll need audit logging.

Managing this complexity is challenging.

💡 Here comes the reality check: it’s the data owner but not the infrastructure operator who is responsible for a breach under GDPR, PCI, CCPA, and most other regulations.

Thus, while some security tasks are handled by your cloud provider, you still have to deal with data security and appsec.

🌁 But how?

The process of making security decisions usually comprises such steps as risk assessment and risk mitigation, threat modelling, loss event scenarios, etc. In a cloud environment, you follow the same steps but make them relevant to the cloud.

☀️ 3 main points to focus on for cloud native security are:

✔️ 1. Minimizing the number of products/tools you use for the same security goal. The less tools, configurations, bugs or dependencies you manage, the better.

✔️ 2. Configuring the preventive, detective, and corrective security controls to protect from different threats but to work for the common goal.

✔️ 3. Building a single data security layer with specific controls (like application level encryption, authentication, firewalling, data loss prevention, anomaly detection, anonymization, etc.).

How exactly to build a data security layer and which tools to use depend on your system design and security requirements.

💡 For example, you can put a database encryption proxy between your app and database to get transparent encryption/decryption without big changes in your solution. (Acra database security suite, available from GitHub, perfectly fits this task.)

Data Access Object (DAO) service can be of help when you have multiple databases (especially a mix of SQL and NoSQL, Acra will help here as well).

And sometimes, the only way to integrate cryptographic code right into your application code is to use an encryption library or SDK (like Themis cryptographic library).

😊 Good thing is that we have already built many different data security layers for various use cases, and know approaches, tools, and typical pitfalls. We’re here to support you in cutting through complexity and protecting your valuable data.

Drop us a line if you face a challenge. And follow our blogs on DEV, our website, and Twitter for more security-related updates. 🔐

10 tips for volunteering devs from data security engineers

Cossack Labs — Tue, 26 Apr 2022 12:47:11 +0000

Many developers are involved now in volunteer work. 🔧🌍 Teams create websites and applications to share useful information for refugees, to organize humanitarian and logistic efforts and even to track military machines.

Are you among those who make this globe run better or save lives in 🇺🇦 Ukraine with your 💪 engineering efforts and software? Let us share with you some observations on how to make this impact even more effective from a security perspective.

▶️ 1. 🎯Focus on your MVP. The idea of adding some sophisticated features to your emergency software before it goes public is tempting but releasing early might help more people. Leave additional features for later. Take it for granted that they’re highly volatile based on available capabilities and people's requests.

▶️ 2. Do software security asap, invite data security engineers early. It saves time and lives. Otherwise, if the security flaws come out in the last stage of the development, they might require re-engineering or compromises one wouldn’t like to have.

▶️ 3. Use risk modeling. Ask yourself “what could go wrong?” often. Be context-wise as some risks that you already know can have much worse adverse consequences in urgent/vulnerable situations. F. ex., during warfare, stakes for data leakage or service unavailability could cost not only GDPR fines, but people’s lives.

▶️ 4. Mind data security. Be careful with data. Don’t collect/store sensitive data. But if you have to, then use encryption for data in transfer, storage, and backup. Take care of the encryption keys.

▶️ 5. Follow OWASP Cheat sheets, OWASP MASVS/MSTG, OWASP ASVS/WSTG. Search for free and available data security services, firewalls, encryption libraries (f. ex., check these must-haves). Move to #2 if currently it’s a hard task.

▶️ 6. Look after physical security:
❇️ Include in your reliability plan events of physical damage or sudden unavailability of the servers/connection lines/data centre, etc.
❇️ If your infra is in a cloud, check other devs/super admin access rights and eliminate risks of unauthorised parties getting access to your systems or losing access to them at all.
❇️ Give preference to low-maintenance and automated infra instead of high-maintenance ones (and move to #1).
❇️ Ensure all team members use long passwords and have multi-factor authentication (MFA) enabled.

▶️ 7. Choose commodity technologies and interoperable solutions rather than those that are rare and hard to replace. You’ll move faster, have more possibilities to find qualified specialists to work with and less problems if something goes unexpected.

▶️ 8. Match your expertise with the projects. F. ex., being experienced in AI/ML or hardware design, you’d better search for initiatives in the same fields as you can contribute to their success more than, say, in frontend development where you have to study first.

▶️ 9. Collaborate and communicate. It is likely that some other people work on the same module/task as you and together you can make it faster. Also, if you build a feature which can be used in, say, 10 projects, your impact is 10x fold and you save lots of time and effort for those 10 teams.

▶️ 10. Match priorities with timing. If you are volunteering during an emergency and want to make an immediate impact, make sure the goal/results of a project you’re contributing to can be achieved within a tight time frame, not “several months/years later”. Switch if an initiative has no chance to win/get to production. During an emergency, losing time can be a disaster. 🔐