Ransomware continues to wreak havoc on global industry, governments, individuals and enterprises. Research shows that more than a third of all businesses were victims of ransomware in 2021, and now over a quarter of all malware has been reprovisioned for ransom. Ransomware is the result of malicious attackers compromising a system or network and exfiltrating or encrypting encountered data; victims are then solicited for return of control or access to their data. In many attacks, separate ransoms are demanded for return of the data and for promises not to release that data publicly.

Existing literature and guidelines on how to best prevent ransomware are common and provide useful tools for most businesses. However, CableLabs has found a distinct lack of support for small and midsized businesses (SMBs). What should SMBs under attack do immediately, what decisions should they make and who should be part of the solution? Answers to these questions were not readily available for those that needed them most.

Responding to the SMB Need

CableLabs’ Security and Privacy Technologies team, through their involvement with the Messaging Malware Mobile Anti-Abuse Working Group (M³AAWG), explored the creation of a Best Common Practices document to help them navigate the intricacies of a ransomware attack. The creation and refinement of this document reflects our commitment to delivering a threat-resistant networking environment for both wired and wireless networks. We would like to thank each of the individuals and the corporations who contributed to this work under the M³AAWG umbrella.

The freely available Ransomware Active Attack Response Best Common Practices document walks the reader through the ransomware recovery process, but it doesn’t provide a single path through the experience. This document should be used to highlight what is important so that businesses can quickly and effectively move forward while identifying the considerations, expert advice and implications of each decision and action. The goal is to inform the technical team about the critical steps to take and to communicate the results so that the executive team can make the best decisions possible in terms of recovery—as well as how best to involve all the other functions in the organization from legal and operations to marketing and financial executives. This document also provides tools for the reader while engaging with those outside the organization, including cybersecurity insurance companies, incident response teams, negotiators, forensic experts, law enforcement, regulators and media.

How It Works

The document’s first three main sections—Detection, Analysis and Response—identify the responsible, accountable, consulted and informed parties, along with the expected deliverables at each stage. The fourth section fleshes out additional details related to the key decisions the team will be making, understanding the timing, implications and involved concerns. The fifth and sixth sections explore the people (both internal and external to the organization) and the technologies at play in the recovery activities. The document closes with post-incident clean-up, recovery and reflection on what led up to the attack, as well as mitigations for the future. The conclusion also includes a review of how each stage progressed—what went well, what didn’t, where was luck involved, what was missed and more.

The target audience for this document is anyone on the IT team within an SMB but primarily the individuals responsible for the technology business operations. This may be a Chief Information Security Officer (CISO) or Chief Information Officer (CIO), or it may be the sales lead who helped build out the network. Not every company has the financial resources or the time to plan for prevention like some larger companies might have, so the objective of this paper was to provide tools in an area that was dramatically devoid of reliable advice. This is a document that the authors hope nobody ever has the necessity to read.

Today, CableLabs® has publicly released a set of best common practices (BCP) to enhance the security of cable modems, integrated access points, and home routers (collectively, known as “gateway devices”) against malicious activity and other cyber threats. This work builds on and extends CableLabs’ and the cable industry’s longstanding leadership in cybersecurity to ensure a consistent and robust baseline for gateway device security, increased economies of scale, and an ontology for simplified communication and procurement between network operators and device manufacturers.

The BCP Working Group is comprised of security technologists from CableLabs, network operators from around the world, and gateway device manufactures, including representatives from CableOne, Charter, Cisco, Cogeco, Comcast, Commscope, Cox, Liberty Global, MaxLinear, MediaCom, Shaw and Technicolor. In developing the BCP, the Working Group drew heavily upon well-established and widely accepted security controls, recognized broadly by industry and government security experts.

The cable industry has long employed extensive network security practices to ensure the confidentiality, integrity and availability of broadband services, including gateway devices. The BCP expands and standardizes these network security practices for gateway devices and complements cable operators’ broader set of security practices. For instance, DOCSIS® Security testing is performed on all gateway devices to ensure DOCSIS protocol conformance, including the verification of the correct implementation of public key infrastructure (PKI) authentication and identity management, BPI+ encryption, and EAE (Early Authentication and Encryption) secure provisioning requirements.

The BCP document goes beyond DOCSIS Security requirements and provides a framework for the full range of security considerations applicable to gateway devices, including hardware and manufacturing considerations, default security settings, configuration procedures, secure boot, roots of trust, software/firmware development and verification, encryption requirements for both data in transit and data at rest, and physical security, among others. To further ensure the robustness of the BCP, the working group compared and mapped the BCP to NIST’s general guidance for connected devices used by the federal government, to help confirm the scope was fully comprehensive of applicable security considerations.

The BCP represents the industry coalescing around a common set of security baseline requirements that furthers the following critical goals:

1. Provide a common framework for security elements and controls within gateway devices, including cable modems, integrated Wi-Fi access points, and home routers, to align the varied approaches to device security across the industry.
2. Create a community of manufacturers and network operators collaborating to enhance gateway device security.
3. Leverage well-established and well-vetted security controls and practices to minimize the risk of unknowingly introduced vulnerabilities or other security weaknesses.
4. Harmonize security requirements across network operators to drive increased economies of scale, lowering the cost of broadband deployment.
5. Further protect network resources and broadband service from malicious attacks.
6. Provide a framework for network operator assurance that enables verification of testable practices and configurations.
7. Enable alignment across standards, regulatory, and compliance regimes through a transparent and open set of best common practices.
8. Establish a security framework for gateway devices that builds in flexibility and agility, so that manufacturers and network operators can address and adapt to new threats and changes in the cyber risk landscape.

While this initial release is an important achievement, one that strives to be comprehensive in terms of security posture for gateway devices, we all recognize that this field is constantly evolving and advancing. We see the BCP as a framework that must and will be updated and maintained as network technology, device security, and unfortunately, adversary techniques continue to evolve. To that end, we invite and welcome additional gateway and modem manufacturers as well as additional network operators to join the working group as we continue to progress this effort.

On October 13, 2021, at 3:00 pm ET, we invite you to join our virtual panel session at SCTE Cable-Tec Expo to discuss and further explore Gateway Device Security and our work to develop the BCP.

Empirical evidence reveals an inimical belief that blockchains and distributed ledger technologies (DLTs) are inherently secure because they use cryptography, employ hashing algorithms and have public/private keypairs—in short, a belief that the data in these systems is extremely unlikely to become exposed. After evaluating requirements and deciding to utilize a blockchain solution, security is important to consider from the start.

Over the past several years, the Security Technologies arm of CableLabs’ Research and Development organization has been tracking blockchain attacks and compromises. From this work, several hazard groupings have been identified. The following list is intended to act as an aid to architecture, design and implementation efforts surrounding enterprise projects that use these technologies.

Smart Contract Injection

The Smart Contract engine is an interpreter for a (sometimes novel) programming language and a parser of data related to the decisions the engine needs to make. The hazard in this situation is when executable code appears inside smart contracts in an effort to subvert the contract language or data. Implementers need to consider sanitizing inputs to smart contracts, proper parsing and error handling.

Replay Attacks

Not only is there a threat in transaction processing and validation, but also in node behavior, authentication, and the securing of confidential messaging. Adding nonces to check against prior transactions is critical.

History Revision Attacks

Blockchains that rely on fault-tolerant consensus models do well when there are many participating nodes processing, competing and collaborating on the next block. When the number of nodes drops, or if there is predictably cyclic behavior, lulls can be leveraged in a history revision attack where a new branch is created, effectively deleting a previously accepted transaction. Designers should consider how to best guarantee minimum support and the diversity of nodes.

Permanence Poisoning

Due to the permanence of blockchains and the cost to fork, it’s possible to sabotage a chain with even claims of illegal content to draw the ire of regulators and law enforcement.

Confidential Information Leaks

Permanence increases the risk of data being exfiltrated out of the chain. Even encrypted data is at risk for future threats against those algorithms or brute-force attacks. Designers need to make sure that they understand the data being stored, how it is protected, who owns it and how it could be re-associated with any pseudonymized users.

Participant Authentication Failure

Are transaction creators cryptographically signing their transactions? Is that signature verified by the protocol? Is transaction receipt confirmed (non-repudiation)? Are sessions managed? Architects need to consider the proof of possession of private keys in the verification and authentication of participants.

Node Spoofing

Nodes are the entities that create and agree on the next new blocks in a chain. Nodes should be authenticated like any other user or system, and authentication must be verified, with multiple votes prohibited. Designers who fail to look for voting irregularities open their implementation to risk.

Node Misbehavior

Nodes that behave incorrectly, intentionally circumventing fault-tolerance mechanisms, or trojan nodes (nodes in public chains that follow the standard protocol but have non-standard implementations) are problematic. Transaction propagation non-compliance is another concern—where nodes don’t convey transactions quickly to other nodes, nodes consistently act in opposition to other nodes, or verifications align consistently within small fiefdoms. In addition, architects need to consider what happens to the chain operations when the chain, the nodes or a subset of the nodes is subject to a denial of service attack.

Untrustworthy Node-Chain Seam

The cryptographic difference between what was intended by the participant, what happens in the node, and what happens on the chain must all be consistent. Architects should enforce a design such that the node is unable to modify a transaction (signing and hash verification), skip a transaction (non-repudiation) or add new transactions (source verification).

General Security Hazards

The hazards fall into this meta-category of general security concerns that have specific implications in the blockchain/DLT realm. Architects, designers and implementers all need to take heed of these practices and work to ensure a complete solution:

• Unproven Cryptography: Look for best practices and proven cryptography in cipher suites, hash algorithms, key lengths, elliptical curves used, etc.
• Non-Extensible Cryptography: Should a foundational algorithm aspect of the chain become compromised, can the chain easily migrate to another suite/hash/key pair? Is there a mechanism and process among node operators to agree and deploy this quickly?
• Security Misconfiguration: Be aware of all code libraries used, stay abreast of the latest security information about deployment technologies such as Docker, and ensure that defaults present in test systems are not available in production systems. Ask if there are any components with known vulnerabilities, determine whether any open ports or file-system permissions may be at risk, and understand protection mechanics for private keys.
• Insufficient Logging and Alerts: If something goes wrong, are there sufficient methods in place to capture actions that occurred (voting, smart contracts, authentication, authorization)? Project managers must ensure that alerts have been added to the code, that the correct recipients have been added at deployment time, and that procedures for constant monitoring and updating of those recipients take place.
• Weak Boundary Defense: Development teams need to be aware of, and shore up, defenses so that there are no exploitable holes in client code or node software, smart contract engines, mobile applications, web applications, chain viewers or administrative tools.

Clearly, this list doesn’t contain everything that must be reviewed in a blockchain or DLT application, but the objective is to provide a few key areas to focus on and provide insight to dive deeper where it makes sense in your own applications. Blockchains can help bridge trust gaps in an ecosystem, but security is foundational to that trust.

Want to learn more about security for blockchain and distributed ledgers in the future? Subscribe to our blog by clicking below. 

A version of this blog was published by S&P Global Market Intelligence.

In IoT security, one of the common arguments is about “how much security” a given device needs (as if we could measure that in grams). The typical example is usually a light bulb. The objective in asking the question this way is usually to vacate some or all of the security requirements for that class of device; the real question we care about, however, is the security available to protect the network, not the just the device.

The light bulb question tricks us into thinking in the wrong frame, it focuses on the device and not the network.

• Why would anyone attack this?
• What would they do if they compromised it, turn my light on and off?

If an attacker were able to compromise the light bulb, they may initially try to test the compromise with a change in command from on to off and back again, but then they would likely not do anything else that would signal the fact that they’ve gained control over that device. The likely target was never the light bulb, this is just a means to an end and part of a larger attack vector.

The light bulb is an interesting initial attack target for several reasons. One of the most pertinent aspects is the fact that the bulb has constant power. The light may be off, but the “smart” element of the bulb is awake and listening to network traffic. The bulb also has a network stack, this is how it communicates with the smart light switch, the rules engine, the family hub, or the owner's phone; this bulb isn’t just listening, it’s also transmitting on that network.

To do this work, the bulb also has a processor; since custom hardware is expensive, that processor can likely perform many functions (so that it can be included in other IoT devices) if not address them all generally. The light bulb also has storage for maintaining state, auditing, and communication, memory to run the operating system and the network stack. Additionally, the bulb also includes drivers for the filament, LEDs, coloration, and dimming aspects of the bulb. Most importantly, when we onboard the light bulb into a network that allows us to control the bulb, we provision that device with networking credentials.

The combination of the above aspects of the smart bulb, combined with either the extremely unlikely chance of discovery or the potentially less likely chance that the firmware or operating system will be updated by the user, make this an excellent first attack point for a network. Once compromised, the attacker can cautiously watch the network, potentially interact with other devices on the same network (including cameras and sensors), spoof other devices, and even perform some physical actions that could compromise the safety of the inhabitants of the home (e.g. by advising the front door to unlock or turning the oven on).

It’s unlikely that anyone - other than a prankster or the neighbor whose house you insist on parking in front of - wants to turn your light off and on. That said, the likelihood of other malicious attacks, the ability to gain access to your network and to the other devices in your home make the light bulb a perfect first step in an attack. A well-known cybersecurity attack principle is lateral movement. An adversary compromises a less protected target on a network and then uses that device or system as a pivot point to perform reconnaissance, move laterally in the network, escalate privileges, and finally reach their objectives.

The ability to find devices such as a light bulb and attack them has never been easier; adversaries can use device identification tools (e.g. shodan.io) to find these light bulbs (both online and as a pin on a map) and then attack them. Some of these light bulbs provide discovery and introspection information that may make for easy interactions within the home but also allow attackers to look up specific attacks based on known vulnerabilities in that bulb’s device and firmware version. These attacks are carried out either locally from a radio within the attacker’s car, or from across the globe, if they’re internet-connected.

Once the light bulb is compromised, they can horizontally attack the rest of the network, attempt to escalate privilege, interact with the other devices, and even use other legitimate devices to spoof interactions with outside equipment, other internet connected services, or other bridged devices within the home. Underestimating the importance of the security for all devices leads to holes in network security and is a path to risk exposure (financial, privacy, safety, litigation, and well-being). It’s not just a light bulb, it’s the network, and that network needs to have strong security.

At CableLabs, we are partnering with manufacturers and working to protect consumers and their networks; to do this, we are contributing device security expertise to IoT standards bodies like OCF and to open-source initiatives like IoTivity. Please join us in these initiatives, either as part of the creation and engineering process or by leveraging this work in your devices.

As of the writing, some of the largest distributed denial-of-service (DDoS) attacks ever are actively disrupting major service and content providers. Many of the attacks are being reported as leveraging Internet of Things devices such as IP cameras. It’s interesting that these dramatic attacks are happening during Cybersecurity Awareness month.

How to Affect Change In Security

For many, IoT literally opens doors; for those of us in need of electronic assistance for key tasks, this is critical for daily living; with an estimated 20 billion devices online four years from now, it is a critical security requirement.  CableLabs is focused on specific goals in securing Internet of Things (IoT) devices for three specific reasons: 1) our desire to protect the privacy and security of our subscribers; 2) enabling trust in the technology automating the environment we live in; and 3) the need to protect the network infrastructure supporting subscriber services. Our technical teams are actively working toward solutions for handling both the heterogeneous security models of existing devices through advanced networking techniques and in future devices through guiding standards bodies and industry coalitions in security considerations.

Who is Looking out for Your Privacy?

Subscriber privacy goes beyond personal anonymity; it includes protecting information that can be used to identify people, or their devices.  Consider a mobile device, such as a Bluetooth fitness band, that broadcasts its unique identifier whenever requested (such as during any handshake to authenticate the device on various networks). That broadcast identifier could be used without the device owner’s knowledge to identify and track shoppers in a mall, protesters, or visitors at medical clinics among other concerns. Interestingly, network protection starts with device identity, and while many put this in opposition to the subscriber privacy, it does not need to be. Prior to onboarding devices into the network, which involves authentication and authorization as well as exchanging credentials and network configuration details, devices can provide temporary random identifier for new onboarding requests. After onboarding into a network, devices need an immutable, attestable, and unique identifier so that network operators can trace malicious behavior. Insecure devices that can evade identification, spoof their network address or misrepresent themselves, all while participating in botnets are a threat to everyone.  Being able to rapidly trace attacks back to offending devices allows operators to more effectively coordinate with device owners in surgically tracking down and quarantining these threats.

Security – Where, When and How

Subscriber security is different from privacy and looks to ensure availability, confidentiality, and integrity.  Availability is the key reason for the need for immutable identifiers within networks. When networked devices are subverted to participate in DDoS attacks, the ability to trace traffic to the corrupted devices is key. Encryption of data (in use, at rest, and in transit) is the primary means of assuring confidentiality. Since many IoT devices are constrained in processing power, it has become easy for manufacturers to overlook the need for confidentiality (data protection), arguing that the processing, storage and power costs for traditional PKI exceed device capabilities. Today, even disposable IoT devices are capable of using PKI thanks to Elliptical Curve Cryptography (ECC). ECC requires smaller keys and enables faster encryption than traditional methods have allowed – all while maintaining the same level of security assurances as traditional (RSA) cryptography. This allows not only for confidentiality, but can also be used to deliver integrity through non-repudiation (a device cannot deny it received a command/message) and message origin assurance (through signing or credential exchange).  However, good ECC curve selection is very important. A final element of security is the ability for these devices to securely update their operating system, firmware, drivers, and protocol stacks. No system is perfect, and when a potential vulnerability is discovered, updating those devices already deployed will be a key part of the success of the IoT and how we interact with these tools.

Forming Trust

These elements described above, availability, privacy, confidentiality, and integrity, all work together to develop trust. This trust comes from personal and shared experiences. The more positive security experiences consumers have with devices, the more trust is earned. Negative experiences deteriorate this trust, and this can happen disproportionally to events which built trust, and it often happens vicariously as opposed to personal experience.  For example, a subscriber who reads about a personal security camera that has been visible to others on the internet,  may forego the purchase of that, or similar, devices. The overall goal is to improve experiences for consumers both in future devices and to limit not only how many devices are compromised, but also limit the scope and impact of any individual vulnerability through leveraging multiple layers of defense.

Working Together Toward Network Protection

When IoT devices can be used en masse to leverage attacks targeting DNS servers, and when consumer market incentives don’t enforce security as a primary concern, industry standards bodies and consortia are typically called on to develop solutions . The Open Connectivity Foundation (OCF) is the leading IoT influence group, with over 200 leading global manufacturers and software developers (Intel, Qualcomm, Samsung, Electrolux, Microsoft and others) joining forces to ensure secure and interoperable IoT solutions. Other ecosystems are converging on OCF as well, and groups like UPnP, the AllSeen Alliance, and OneM2M have merged into the OCF organization. CableLabs and network operators including Comcast and Shaw are part of this movement, contributing code, technical security expertise, leadership, specifications, and time to make the Internet of Things safer for everyone. The Linux Foundation project, IoTivity, is being built as a platform to enable device manufacturers to more economically include security and interoperability in their products. OCF is driving toward support within IoT devices for subscriber privacy, security, and trust.

Standards organizations tend to focus on future devices, but helping manage existing devices is another area of research and exploration. The IoT security community is actively engaged not only on the future, but on the present, and how to improve consumer, manufacturer and operator experiences. A key tool to support existing IoT systems will be intermediating device/internet connections and providing bridges between ecosystems for interoperability to the ideas around using advanced networking techniques to help manage devices.

Convergence

These different needs, privacy, security, trust and network protection, all combine to create a positive perspective on the IoT environment.  Imagine devices which are highly available, trusted to do what they need to do, when they need to, for only whom they are intended to, and that communicate across networks securely, all while maintaining privacy. This is the focus of component and device manufacturers, network operators, integrators, academics, and practitioners alike.  The convergence we are seeing around standards and open source projects is great news for all of us.

Interested in learning more?  Join Brian and several others at the Inform[ED]™ Conference in New York, April 12, 2017.

Brian A. Scriber (@brianscriber), Principal Architect, Security, CableLabs is the Security Working Group Chair, Open Connectivity Foundation (OCF) (@OpenConnOrg).

During the season of Lent in my upbringing meant I was going to be giving something up. This year, instead of giving something up, I have decided to help those around me clean up their security and suggest you help a friend in turn.  Statistics show that you probably know someone who could use a hand modifying their most egregious electronic security habits - maybe we should term it "insecurity habits."  None of us are perfect but these three initial steps will help your friend.

1. Passwords

My favorite place to start!

• Stop using the same password for every website and app. Yes, it's 2016, but I have just recently had a site send me my plaintext password when I tried to reset it.  That means that site is not storing it in hashed form and it means they are vulnerable to breach - along with everyone with an account on their site.  Should a hacker obtain one of your passwords, they will now be able to access multiple sites.

• Use a password manager.  Your friend will have to remember one more quality password, but that's it.  Suggest to your friend that they pick one that can be installed on a smartphone and with strong encryption (e.g. AES 256).  Keep private information in this tool - don't keep your passport and social security numbers in notes since those records need to be secured.  Usually the password manager has a couple of extra fields for each account, these can be used to store the answers to the challenge questions like "What is your mother's maiden name?"

• Use Strong passwords.  It's easy to remember, but password1 and similar others are easy to hit when running a password cracker.  Your friend has a password manager now, have it generate the passwords – this automation of a task actually takes one step out of the password dance.

• Insist on two factor authentication.  When your friend uses critical accounts, including e-mail, (where do you think banks send the password reset links?), they should be requiring a code to be texted to their cell phone.  If they ever get a text when not logging into their account, they will know they have been attacked, if not compromised.

2. Mobile devices

Ten years ago this covered laptop computers and maybe a Palm Pilot, now it means so much more.  Your friend's fitness watch, even after pairing, is likely still broadcasting its identity in its communication - this is interesting because it means your friend can be tracked as he travels through the mall, or in a grocery store, even aggregating data from multiple sources to further profile them.  We can't stop everything, but there are a couple steps your friend can take here too.

• Ask about security when purchasing devices. This serves a few purposes. First, it informs you about what the manufacturer is claiming - this is important for your friend's education now, and in the future he or she may need to show that the claim of security was made in a way that was communicated clearly. The second purpose is to have all of us drive the market. By asking salespeople about security features, it provides feedback that they in turn use to inform their wholesale representatives and provide retail reordering criteria. This information absolutely makes it back to the marketing departments, which in turn helps fund engineering efforts to protect all of us.

• Update the operating system and firmware on devices. This is more important than most people realize. When a device has an old version of firmware, especially one that can be identified, that device is going to be targeted. There are suites of tools that can be used to attack once the operating system or firmware is known. Your friend may think “what do I have to hide?” but the truth of that is their identity, access to their device, access to their communications, access to their home in cases of physical security devices and access to their financial institutions are all at risk, and what they don’t know can hurt them.

• Don't plug into USB charging ports directly.  USB Cables carry both power and data; it's the latter your friend needs to be concerned with. It may look convenient to plug into the USB port on the wall, or in the seat-back console ahead of you on the airplane, but you’re plugging into a black box that could be compromised or the port could be accessible to other networked devices. Once you plug your device in directly, brute force attacks are much easier. Use the power adapter for wall sockets, or find a device that lets you plug the USB into an adapter that strips the data lines off the USB and allows only power to pass through.

• Set a strong access code. Just like passwords, above, your friend’s device shouldn’t have a password like 1234 or 1111. Convince them to use an alphanumeric code or complicated gesture. Particularly if their device has a biometric reader like a fingerprint scanner, there’s no reason for them to not have a password that is more difficult to guess.

3. Vigilance

Some of this may seem like common sense, but I can assure you and your friend that I continue to come across examples where simple social inertia (“that’s the way we’ve always done it”) plays a strong role in how we interact with each other. Take the fax machine as an example. Faxes are not secure. Healthcare providers need to stop using technology from the 1990s to transfer our “protected” health information.

• Emailing important documents. In 2015 I went through a refinance of my home. During that process critical documents were emailed to me either in plain text or as unencrypted attachments. The expectation was that I was going to review them, complete them, sign them, scan them, and send them back via email. When I pointed out the problem, I was told that they receive thousands of documents this way and that the IT department said it was okay. It’s not okay. The underlying protocol for email can leave copies of your friend’s email on servers along the route and those copies can fall into the wrong hands. Additionally, if your friend’s email account is ever compromised, those documents in the Sent folder will be scanned in the search for financial data. Instead of emailing, have your friend ask the other party for a secure portal where you can upload the documents.

• Social engineering and phishing. It is disappointing that we use cute terms like these for what’s really happening: fraud. Remind your friend to be alert when called on the phone to not give out confidential information such as whether or not they are at home or the names of their direct reports. When your friend receives an email with a link – especially from the bank, never click on the link. Instead, your friend should go to the bank site directly from a bookmark or typed into the navigation bar (even if the email link appears safe, it may have a URL with letters that look similar to our alphabet but actually use alternate languages/encodings to appear valid). Your friend should be aware to whom they are providing what information, and how do they know to whom they are speaking.

• Storing credit cards. Simply put, strongly suggest that your friend not do this. It’s super convenient to not type it in, but your friend needs to know that if their account with that merchant is ever compromised, the attackers can change the ship-to address and order goods or services with the stored payment information. If your friend didn’t follow your advice, and kept the same password for multiple sites, they could also be vulnerable when one site gets compromised

• Question the need for sharing data. This last awareness step is one of those things that we have all probably questioned, but we need to do it more. The company from which I’m buying a sweatshirt doesn’t need me to create an account for that transaction. If I do create an account, I’m certainly not going to provide answers to all of the challenge questions. They don’t need to know most of the information they are asking. Encourage your friend to push back whenever possible or to provide answers that don’t compromise confidentiality. This goes beyond online forms and includes merchants that want to know your friend’s zip code, phone number or email address. That data needs be shared only if your friend wants to communicate with the merchant.

Now that you’ve looked at these recommendations for your friend, maybe there were a couple things that stuck for you as well. Don’t forget to forward these suggestions to your friend so that you may help them out this year.

Brian Scriber is a security architect with CableLabs focusing on cryptography and security for the Internet of Things – he researches things like thermostats that can talk refrigerators into sharing usage data and joining their botnet. Follow Brian on Twitter.