Technology Advisor Blog

Phishing:  Would your employees click on any of these emails?

Posted by Ann Westerheim on 3/15/18 2:02 PM

Phishing with Fish.jpgEveryone thinks they won't click on a phishing link, but when we run tests, there's always someone who does!

Phishing is the leading tactic used by today's ransomware hackers, typically delivered in the form of an email designed to impersonate a real system or organization.  Often created to deliver a sense of urgency and importance, the message within these emails often appears to be from the government or a major corporation and can include logos and branding.  They look like the real thing!

Would any of your employees click on these emails?

  • Tax Refund - Recipient is due a tax refund and directed to a site to claim their refund.
  • Bank Account Low Balance - Recipient receives a low balance alert in the bank account and gives them the option to check their account.
  • Amazon Security Alert - Alerts Amazon customer that there were several unauthorized attempts to access their account from an unknown device
  • DocuSign Signature Request - Recipient is sent a request to electronically sign a document
  • Webinar Reminder - Recipient is sent an email reminder that the webinar will begin in 1 hour.
  • Netflix Account Reset - Netflix password has been reset and asks the target to change their password.
  • IT Reset Password - Email sent from IT asking to reset password
  • eFax Email - eFax email with instructions to download the electronic fax.

These are all examples of typical phishing scenarios, and are actual emails we use as part of of cybersecurity training.  Everyone thinks they won't click on the link, but when we run training tests, there is always at least one person who clicks on the link.

In a test scenario, the user is just warned that they made a mistake and its an educational moment.  However, if the email was malicious, this could take down an entire organization with ransomware.  

The concept of a "human firewall" is getting a lot of attention these days.  A network firewall, security patch updates, DNS protection, and all the technical layers of protection needed for responsible network protection are just part of the solution.  The behavior of all users on your network will also impact your security (and the bad actors know it!).  Don't forget employee security training as part of your overall cybersecurity strategy.

Tags: HIPAA, cybersecurity, ransomware, training, Microsoft Security Patches

What's a "Patch Policy" and why do I need one?

Posted by Ann Westerheim on 8/26/14 7:54 AM

Security Patch PolicySecurity is the top technology concern among small business owners, and the flood of information about new security threats can seem overwhelming at times.  Just about every week we see a new headline about a new threat or breach.  

One of the most important actions to protect against threats is to keep your software up to date.  In fact, the Massachusetts Data Security Law and other industry-specific compliance rules require up to date security updates:  "For files containing personal information on a system that is connected to the Internet, there must be reasonably up-to-date firewall protection and operating system security patches..."  

Every month, Microsoft releases new security updates on "Patch Tuesday" which is the second Tuesday of the month.  These security updates are free with your licensed products, but they need to be installed to be effective.  As you may know, you can turn on "automatic" updates with Microsoft, and get all the updates, but in many cases, blindly installing the updates can be a problem in a business environment and we don't recommend Automatic Updates. This is why our "best practice" is to test updates before installation and create a "patch policy" to manage installation.  Just last week, Microsoft repealed security updates that were linked to blue-screened systems.  The software is so complex, and occasionally a patch gets released that has unintended interactions.  One of the most common is that many line-of-business applications won't run with the latest version of Internet Explorer, and a blind update will cause problems.  

We get a lot of questions about this, and we thought it would be useful to explain the reasoning behind the generation of a patch policy.  As a general rule, we'll install all Microsoft Operating System, Office, and other critical patches after testing.  In general, critical patches will be tested within 24 hours, and lower priority patches will be tested within one to two weeks.  

Sometimes customers look at the Automatic Updates information from Microsoft and become alarmed that they are not getting automatic updates, and the reason is that we test patches first.  Our software monitors for patch compliance, and we are automatically notified when there is a problem and we can report back to users as needed.  Each month, we review the list of installed patches and have a person on our team who specifically reviews sites every day for compliance.

Additional patches that are installed include Apple operating system patches (for MACs), and also "third party" patches such as Adobe Acrobat, Flash, Reader, Safari, Mozilla Firefox, Java, among others.  As a general rule, we install hardware drivers on an as-needed basis as these are very specific to different systems and configurations.

The next most important feature of a patch strategy is to manage reboots.  Many security patches require reboots for installation, and some patches are sequential in that the next patch can't install before the first installation is complete.  For servers, we generally program a scheduled reboot after security patch installation at a scheduled time to minimize disruption to the office (generally in the midnight to 5am window).  In a few cases, some line-of-business applications are known to not gracefully start after a reboot, and instead we schedule attended reboots so that the server and applications can be checked after the reboot.  We'll call the office and schedule a specific time that works.

For desktops, we generally don't schedule forced reboots because of the potential disruption this can cause a user.  If someone forgets to close an important document, or they're working at an odd time, a scheduled reboot can be annoying.  Also, if a system is "asleep" during the scheduled time, the reboot will be attempted when the computer is "awake" again, and this can be annoying as well.  We monitor reports of systems in need of reboot, and typically communicate with the office to let them know who needs a reboot.  Also we ask all users to reboot at least weekly.  In a few cases, we have scheduled site-wide reboot times, and if we see consistent problems with reboot compliance, we will strongly recommend this.

Data security is critical for protecting your business, and security updates are the first line of defense.  Every month we get questions about security patches, and we hope this post has addressed some of your questions.  Let us know!

 

Tags: Microsoft Security Patches, Patch Policy, Compliance

Subscribe by Email

Most Popular Posts

Browse by Tag

See all tags...

Connect With Us

Older Blog Posts

For older Ekaru blog posts, go to ekaru.blogspot.com.