September 2019 - Managed IT Services | IT Support | SF Bay Area & Los Angeles

Smishing Explained: What It Is and How You Can Prevent It

Do you remember the last time you’ve interacted with a brand, political cause, or fundraising campaign via text message? Have you noticed these communications occurring more frequently as of late?

It’s no accident. Whereas marketers and communications professionals can’t count on email opens or users accepting push notifications from apps, they’re well aware that around 98% of SMS messages are read within seconds of being received

As with any development in how we communicate, the rise in brand-related text messaging has attracted scammers looking to profit. Hence we arrive at a funny new word in the cybersecurity lexicon, “smishing.” Mathematical minds might understand it better represented by the following equation:

SMS + Phishing = Smishing

For the rest of us, smishing is the act of using text messages to trick individuals into divulging sensitive information, visiting a risky site, or downloading a malicious app onto a smartphone. These often benign seeming messages might ask you to confirm banking details, verify account information, or subscribe to an email newsletter via a link delivered by SMS.

As with phishing emails, the end goal is to trick a user into an action that plays into the hands of cybercriminals. Shockingly, smishing campaigns often closely follow natural disasters as scammers try to prey on the charitable to divert funds into their own pockets.

Smishing vs Vishing vs Phishing

If you’re at all concerned with the latest techniques cybercriminals are using to defraud their victims, your vocabulary may be running over with terms for the newest tactics. Here’s a brief refresher to help keep them straight.

Smishing, as described above, uses text messages to extract the sought after information. Different smishing techniques are discussed below.
Vishing is when a fraudulent actor calls a victim pretending to be from a reputable organization and tries to extract personal information, such as banking or credit card information.
Phishing is any type of social engineering attack aimed at getting a victim to voluntarily turn over valuable information by pretending to be a legitimate source. Both smishing and vishing are variations of this tactic.

Examples of Smishing Techniques

Enterprising scammers have devised a number of methods for smishing smartphone users. Here are a few popular techniques to be aware of:

Sending a link that triggers the downloading of a malicious app. Clicks can trigger automatic downloads on smartphones the same way they can on desktop internet browsers. In smishing campaigns, these apps are often designed to track your keystrokes, steal your identity, cede control of your phone to hackers, or encrypt the files on your phone and hold them for ransom.
Linking to information-capturing forms. In the same way many email phishing campaigns aim to direct their victims to online forms where their information can be stolen, this technique uses text messages to do the same. Once a user has clicked on the link and been redirected, any information entered into the form can be read and misused by scammers.
Targeting users with personal information. In a variation of spear phishing, committed smishers may research a user’s social media activity in order to entice their target with highly personalized bait text messages. The end goal is the same as any phishing attack, but it’s important to know that these scammers do sometimes come armed with your personal information to give their ruse a real feel.
Referrals to tech support. Again, this technique is a variation on the classic tech support scam, or it could be thought of as the “vish via smish.” An SMS message will instruct the recipient to contact a customer support line via a number that’s provided. Once on the line, the scammer will try to pry information from the caller by pretending to be a legitimate customer service representative.

How to Prevent Smishing

For all the conveniences technology has bestowed upon us, it’s also opened us up to more ways to be ripped off. But if a text message from an unknown number promising to rid you of mortgage debt (but only if you act fast) raises your suspicion, then you’re already on the right track to avoiding falling for smishing.

Here are a few other best practices for frustrating these attacks:

Look for all the same signs you would if you were concerned an email was a phishing attempt: 1) Check for spelling errors and grammar mistakes, 2) Visit the sender’s website itself rather than providing information in the message, and 3) Verify the sender’s telephone address to make sure it matches that of the company it purports to belong to.
Never provide financial or payment information on anything other than the trusted website itself.
Don’t click on links from unknown senders or those you do not trust
Be wary of “act fast,” “sign up now,” or other pushy and too-good-to-be-true offers.
Always type web addresses in a browser rather than clicking on the link.
Install a mobile-compatible antivirus on your smart devices.

This article was provided by our service partner : webroot.com

How policy based backups will benefit you

With VMworld 2019 right around the corner, we wanted to share a recap on some of the powerful things that VMware has in their armoury and also discuss how Veeam can leverage this to enhance your Availability.

This week VMware announced vSAN 6.7 Update 3. This release seems to have a heavy focus on simplifying data center management while improving overall performance. A few things that stood out to me with this release included:

Cleaner, simpler UI for capacity management: 6.7 Update 3 has color-coding, consumption breakdown, and usable capacity analysis for better capacity planning allowing administrators to more easily understand the consumption breakdown.
Storage Policy changes now occur in batches. This ensures that all policy changes complete successfully, and free capacity is not exhausted.
iSCSI LUNs presented from vSAN can now be resized without the need to take the volume offline, preventing application disruption.
SCSI-3 persistent reservations (SCSI-3 PR) allow for native support for Windows Server Failover Clusters (WSFC) requiring a shared disk.

Veeam is listed in the vSAN HCL for vSAN Partner Solutions and can protect and restore VMs. The certification for the new Update 3 release is also well on its way to being complete.

Another interesting point to mention is the Windows Server Failover Clusters (WSFC). While these are seen as VMDKs, they are not applicable to the data protection APIs used for data protection tasks. This is where the Veeam Agent for Microsoft Windows comes in with the ability to protect those failover clusters in the best possible way.

What is SPBM?

Storage Policy Based Management (SPBM) is the vSphere administrator’s answer to control within their environments. This framework allows them to overcome upfront storage provisioning challenges, such as capacity planning, differentiated service levels and managing capacity resources in a much better and efficient way. All of this is achieved by defining a set of policies within vSphere for the storage layer. These storage policies optimise the provisioning process of VMs by provisioning specific datastores at scale, which in turn will remove the headaches between vSphere admins and storage admins.

However, this is not a closed group between the storage and virtualisation admins. It also allows Veeam to hook into certain areas to provide better Availability for your virtualised workloads.

SPBM spans all storage offerings from VMware, traditional VMFS/NFS datastore as well as vSAN and Virtual Volumes, allowing policies to overarch any type of environment leveraging whatever type of storage that is required or in place.

What can Veeam do?

Veeam can leverage these policies to better protect virtual workloads, by utilising vSphere tags on old and newly created virtual machines and having specific jobs setup in Veeam Backup & Replication with specific schedules and settings that are required to meet the SLA of those workloads.

Veeam will also back up any virtual machine that has an SPBM policy assigned to it, as well as protect the data. It will also protect the policy, so if you had to restore the whole virtual machine, the policy would be available as part of the restore process.

Automate IT

Gone are the days of the backup admin adding and removing virtual machines from a backup job, so let’s spend time on the interesting and exciting things that provide much more benefit to your IT systems investment.

With vSphere tags, you can create logical groupings within your VMware environment based on any characteristic that is required. Once this is done, you are able to migrate those tags into Veeam Backup & Replication and create backup jobs based on vSphere tags. You can also create your own set of vSphere tags to assign to your virtual machine workloads based on how often you need to back up or replicate your data, providing a granular approach to the Availability of your infrastructure.

VMware Snapshots – The vSAN way

In vSAN 6.0, VMware introduced vSAN Sparse Snapshots. The snapshot implementation for vSAN provides significantly better I/O performance. The good news for Veeam customers is if you are using the traditional VMFS or the newer vSAN sparse snapshots the display and output are the same — a backup containing your data. The benefits are incredible from a performance and methodology point of view when it comes to the sparse snapshot way and can play a huge role in achieving your backup windows.

The difference between the “traditional” and the new snapshot methodology that both vSAN as well as Virtual Volumes leverage is that a traditional VMFS snapshot is using Redo logs which, when working with high I/O workloads, could cause performance hits when committing those changes back to the VM disk. The vSAN way is much more similar to a shared storage system and a Copy On Write snapshot. This means that there is no commitment after a backup job has released a snapshot, meaning that I/O can continue to run as the business needs.

There are lots of other integrations between Veeam and VMware but I feel that this is still the number one touch point where a vSphere and Backup Admin can really make their life easier by using policy-based backups using Veeam.

This article was provided by our service partner : veeam.com

Why You Shouldn’t Share Security Risk

There are some things in life that would be unfathomable to share. Your toothbrush, for example. We need to adopt the same clear distinction with cybersecurity risk ownership as we do with our toothbrush.

You value sharing as a good characteristic. However, even if you live with other people, everyone in your household still has their own toothbrush. It’s very clear which toothbrush is yours and which toothbrush is your partner’s/spouse’s or your children’s.

At some point in our lives, we were taught that toothbrushes should not be shared, and we pass that knowledge down to our children and dependents and make sure they also know. The same type of education about not sharing cybersecurity risks needs to happen. By not defining risk ownership, you’re sharing it with your customers.

Why Risk Should Never Be Shared

There should be no such thing as shared risk. It is very binary. Either the customer owns it, or you own it. Setting the correct expectation of an MSP’s cybersecurity and risk responsibility is critical to keeping a long-term business relationship.

When a breach occurs is not the time to be wondering which side is at fault. Notice I said ‘when’ not ‘if.’ Nearly 70% of SMBs have already experienced a cyberattack, with 58% of SMBs experiencing a cybersecurity attack within the past year—costing these companies an average of $400,000. The last thing you need is to be on the hook for a potentially business-crippling event. You need to limit your liability.

What Are Your Cybersecurity Risk Management Options?

1. Accept the Risk

When an organization accepts the risk, they have identified and logged the risk, but don’t take any action to remediate it. This is an appropriate action when the risk aligns with the organization’s risk tolerance, meaning they are willing to leave the risk unaddressed as a part of their normal business operations.

There is no set severity to the risk that an organization is willing to accept. Depending on the situation, organizations can accept risk that is low, moderate, or high.

When an organization decides to accept the risk, they have identified and logged the risk, but don’t take any action to remediate it. This is an appropriate action when the risk fits into the organization’s risk tolerance, and there is no set severity to the risk. Meaning, depending on the situation, an organization could be willing to accept low, moderate, or even high risk.

Here are two examples:

An organization has data centers located in the northeastern part of the United States and accept the risk of earthquakes. They know that an earthquake is possible but decide not to put the money into addressing the risk due to the infrequency of earthquakes in that area.

On the other end of the risk spectrum, a federal agency might share classified information with first responders who don’t typically have access to that information to stop an impending attack.

Many factors go into an organization accepting risk, including the organization’s overall mission, business needs, and potential impact on individuals, other organizations, and the Nation.1

2. Transfer the Risk

Transferring risk means just that; an organization passing the identified risk onto another entity. This action is appropriate when the organization has both the desire and the means to transfer the risk. As an MSP, you make a recommendation to a customer and they want you to do something, they’ve transferred the risk to you in exchange for payment for your products and service.

Transferring risk does not reduce the likelihood of an attack or incident occurring or the consequences associated with the risk.2

3. Mitigate the Risk

When mitigating risk, measures are put in place to address the risk. It’s appropriate when the risk cannot be accepted, avoided, or transferred. Mitigating risk depends on the risk management tier, the scope of the response, and the organization’s risk management strategy.

Organizations can approach risk mitigation in a variety of ways across three tiers:

Tier 1 can include common security controls
Tier 2 can introduce process re-engineering
Tier 3 can be a combination of new or enhanced management, operational, or technical safeguards

An organization could put this into practice by, for example, prohibiting the use or transport of mobile devices to certain parts of the world.3

4. Avoid the Risk (Not Recommended)

Risk avoidance is the opposite of risk acceptance because it’s an all-or-nothing kind of stance. For example, cutting down a tree limb hanging over your driveway, rather than waiting for it to fall, would be risk avoidance. You would be avoiding the risk of the tree limb falling on your car, your house, or on a passerby. Most insurance companies, in this example, would accept the risk and wait for the limb to fall, knowing that they can likely avoid incurring that cost. However, the point is that risk avoidance means taking steps so that the risk is completely addressed and cannot occur.

In business continuity and disaster recovery plans, risk avoidance is the action that avoids any exposure to the risk whatsoever. If you want to avoid data loss, you have a fully redundant data center in another geographical location that is completely capable of running your entire organization from that location. That would be complete avoidance of any local disaster such as an earthquake or hurricane.

While risk avoidance reduces the cost of downtime and recovery and may seem like a safer bet, it is usually the most expensive of all risk mitigation strategies. Not to mention it’s simply no longer feasible to rely on risk avoidance in today’s society with increasingly sophisticated cyberattacks.4

By using a risk assessment report to identify risk, you can establish a new baseline of the services you are and are not covering. This will put the responsibility onto your customers to either accept or refuse your recommendations to address the risk.

Summary

There are many different options when it comes to dealing with risks to your business. The important thing is to know what risks you have, how you are going to manage those risks, and who owns those risks. Candid discussions with your customers, once you know and understand the risks, is the only true way for each of you to know who owns the risks and what risk management option is going to be put in place for those risks. Don’t be afraid to have these conversations. In the long run, it will lead to outcomes which will be best for both you and your customers.

This article was provided by our service partner : Connectwise

Healthcare backup vs record retention

Healthcare overspends on long term backup retention

There is a dramatic range of perspective on how long hospitals should keep their backups: some keep theirs for 30 days while others keep their backups forever. Many assume the long retention is due to regulatory requirements, but that is not actually the case. Retention times longer than needed have significant cost implications and lead to capital spending 50-70% higher than necessary. At a time when hospitals are concerned with optimization and cost reduction across the board, this is a topic that merits further exploration and inspection.

Based on research to date and a review of all relevant regulations, we find:

There is no additional value in backups older than 90 days.
Significant savings can be achieved through reduced backup retention of 60-90 days.
Longer backup retention times impose unnecessary capital costs by as much as 70% and hinder migration to more cost-effective architectures.
Email retention can be greatly shortened to reduce liability and cost through set policy.

Let’s explore these points in more details.

What are the relevant regulations?

HIPAA mandates that Covered Entities and Business Associates have backup and recovery procedures for Patient Health Information (PHI) to avoid loss of data. Nothing regarding duration is specified (CFR 164.306, CFR 164.308). State regulations govern how long PHI must be retained, usually ranging from six to 25 years, sometimes longer.

The retention regulations refer to the PHI records themselves, not the backups thereof. This is an important distinction and a source of confusion and debate. In the absence of deeper understanding, hospitals often opt for long term backup retention, which has significant cost implications without commensurate value.

How do we translate applicable regulations into policy?

There are actually two policies at play: PHI retention and Backup retention. PHI retention should be the responsibility of data governance and/or application data owners. Backup retention is IT policy that governs the recoverability of systems and data.

I have yet to encounter a hospital that actively purges PHI when permitted by regulations. There’s good reason not to: older records still have value as part of analytics datasets but only if they are present in live systems. If PHI is never purged, records in backups from one year ago will also be present in backups from last night. So, what value exists in the backups from one year ago, or even six months ago?

Keeping backups long term increases the capital requirements, complexity of data protection systems, and limits hospitals’ abilities to transition to new data protection architectures that offer a lower TCO, all without mitigating additional risk or adding additional value.

What is the right backup retention period for hospital systems?

Most agree that the right answer is 60-90 days. Thirty days may expose some risk from undesirable system changes that require going further back at the system (if not the data) level; examples given include changes that later caused a boot error. Beyond 90 days, it’s very difficult to identify scenarios where the data or systems would be valuable.

What about legacy applications?

Most hospitals have a list of legacy applications that contain older PHI that was not imported into the current primary EMR system or other replacement application. The applications exist purely for reference purposes, and they often have other challenges such as legacy operating systems and lack of support, which increases risk.

For PHI that only exists in legacy systems, we have only two choices: keep those aging apps in service or migrate those records to a more modern platform that replicates the interfaces and data structures. Hospitals that have pursued this path have been very successful reducing risk by decommissioning legacy applications, using solutions from Harmony, Mediquant, CITI, and Legacy Data Access.

What about email?

Hospitals have a great deal of freedom to define their email policies. Most agree that PHI should not be in email and actively prevent it by policy and process. Without PHI in email, each hospital can define whatever email retention policy they wish.

Most hospitals do not restrict how long emails can be retained, though many do restrict the ultimate size of user mailboxes. There is a trend, however, often led by legal to reduce the history of email. It is often phased in gradually: one year they will cut off the email history at ten years, then to eight or six and so on.

It takes a great deal of collaboration and unity among senior leaders to effect such changes, but the objectives align the interests of legal, finance, and IT. Legal reduces discoverable information; finance reduces cost and risk; and IT reduces the complexity and weight of infrastructure.

The shortest email history I have encountered is two years at a Detroit health system: once an item in a user mailbox reaches two years old, it is actively removed from the system by policy. They also only keep their backups for 30 days. They are the leanest healthcare data protection architecture I have yet encountered.

Closing thoughts

It is fascinating that hospitals serving the same customer needs bound by vastly similar regulatory requirements come to such different conclusions about backup retention. That should be a signal that there is real optimization potential both with PHI and email. You can also consider Foresee Medical and learn about this healthcare software.

This article was provided by our service partner : veeam.com