It’s Dev, not Diva – Don’t set the “stage” for failure

Development: the act, process, or result of developing, the development of new ideas. This is one of the Merriam-Webster definitions of development.

It doesn’t really matter what you call it…dev, development, stage, test. Software applications tend to be in flux, and the developers, programmers, testers, and ancillary staff need a place to work on them.

Should that place be out on the internet? Let’s think about that for a minute. By their very nature, dev environments aren’t complete. Do you want a work in progress, with unknown holes, to be externally facing? This doesn’t strike me as the best idea.

But, security peeps, we HAVE to have it facing the internet – because REASONS! (Development types…tell me what your valid reasons are?)

And it will be fine – no one will find it, we won’t give it a domain name!

Security through obscurity will not be your friend here…with the advent of Shodan, Censys.io, and other venues…they WILL find it. Ideally, you should only allow access via VPN or other secure connection.

What could possibly go wrong? Well, here’s a short list of SOME of the things that MSI has found or used to compromise a system, from an internet facing development server:

  • A test.txt file with sensitive information about the application, configuration, and credentials.
  • Log files with similar sensitive information.
  • .git directories that exposed keys, passwords, and other key development information.
  • A development application that had weak credentials was compromised – the compromise allowed inspection of the application, and revealed an access control issue. This issue was also present in the production application, and allowed the team to compromise the production environment.
  • An unprotected directory that contained a number of files including a network config file. The plain text credentials in the file allowed the team to compromise the internet facing network devices.

And the list keeps going.

But, security peeps – our developers are better than that. This won’t happen to us!

The HealthCare.Gov breach https://www.csoonline.com/article/2602964/data-protection/configuration-errors-lead-to-healthcare-gov-breach.html in 2014 was the result of a development server that was improperly connected to the internet. “Exact details on how the breach occurred were not shared with the public, but sources close to the investigation said that the development server was poorly configured and used default credentials.”

Another notable breach occurred in 2016 – an outsourcing company named Capgemini https://motherboard.vice.com/en_us/article/vv7qp8/open-database-exposes-millions-of-job-seekers-personal-information exposed the personal information of millions of job seekers when their IT provider connected a development server to the internet.

The State of Vermont also saw their health care exchange – Vermont Connected – compromised in 2014 https://www.databreachtoday.asia/hackers-are-targeting-health-data-a-7024 when a development server was accessed. The state indicates this was not a breach, because the development server didn’t contain any production data.

So, the case is pretty strongly on the side of – internet facing development servers is a bad idea.

Questions? Comments? What’s your take from the development side? I’d love to hear from you – lwallace@microsolved.com, or @TheTokenFemale on Twitter!

 

 

 

 

 

 

 

 

 

 

Lighting up BEC, not Bic – Business Email Compromise…

What’s a bit of spam and a bit of phishing, right? It’s all the cost of doing business…until you look at what it really CAN cost your business.

The latest statistics from the Internet Crime Complaint Center (IC3) are enlightening – taken directly from the IC3 site:

The following BEC/EAC statistics were reported to the IC3 and are derived from multiple sources, including IC3 and international law enforcement complaint data and filings from financial institutions between October 2013 and May 2018:

Domestic and international incidents: 78,617
Domestic and international exposed dollar loss: $12,536,948,299

The following BEC/EAC statistics were reported in victim complaints where a country was identified to the IC3 from October 2013 to May 2018:

Total U.S. victims: 41,058
Total U.S. victims: $2,935,161,457
Total non-U.S. victims: 2,565
Total non-U.S. exposed dollar loss: $671,915,009

The following BEC/EAC statistics were reported by victims via the financial transaction component of the IC3 complaint form, which became available in June 20163. The following statistics were reported in victim complaints to the IC3 from June 2016 to May 2018:

Total U.S. financial recipients: 19,335
Total U.S. financial recipients: $1,629,975,562
Total non-U.S. financial recipients: 11,452
Total non-U.S. financial recipients exposed dollar loss: $1,690,788,278

That’s billions with a B…and the dollars and cents cannot measure the intangible costs like reputation, consumer confidence, etc.

What are the growing targets, and vectors of compromise? Financial transactions of all kinds tend to be the low hanging fruit. Real estate transactions, wire transfers, anything with a routine methodology of process, where information requests are constant, and a change of source or target would not be unusual. What’s another call from the bank, asking to verify your account information for payment? Another wire transfer request from the CFO?

There are also information breaches to consider. Let’s look at DocuSign for a moment – their own statement admits that email addresses were compromised, but indicates that additional personal information was not at risk. This statement is a bit misleading. A threat actor could collate the additional info to make an attack appear legitimate through other sources – and the fact that these emails came from DocuSign means that they would legitimately expect to receive email FROM DocuSign! In sales, that’s a pre-qualified lead, and it’s no less valuable to an attacker.

Another high-profile incident is the indictment of Russian operatives in the DCCC and DNC compromise – MSI has written about that here.

Add the preponderance of mobile devices, webmail, and online portals to your business of all kinds…it’s a risk. And any breach of your business data, client/customer data, and/or employee data is high profile as a risk to YOU. MSI has had a number of clients this year with compromises of Office 365 email accounts, administrative accounts that were externally facing, wire transfer issues, etc. On a personal level, individuals have had fraudulent tax returns filed under their SSN, etc. Size is irrelevant when it’s your data (and money) at risk.

So, what can you do to protect yourself, and your company? Email filtering, mobile device management, and other security measures can help – but the one measure that is consistently most effective against these attacks is MFA – multi-factor authentication. MFA is, at its core, something you know and something you have.

Often, this is an SMS code, or something physical like an RSA hard or soft token. However, do not rule out MFA for less technical transactions. In a situation where the CFO emails in a wire transfer, also add a vocal component – the individual must call and answer a challenge response question.

Are there challenges to implementing MFA? Of course. One of the primary challenges is user resistance – one of my favorite sayings is…change is inevitable, except in vending machines. But humans are wired to see their consistent patterns as a comfort, and you’re asking them to leave their comfort zone.

Another challenge is the technology gap. NIST is no longer recommending SMS as a component of MFA – but if that is all your organization is capable of leveraging, is it better than nothing? That’s a question for your technical and risk staff to consider.

The solution you choose will always NOT work for someone or something in your organization – someone will have a device that is too old, or incompatible, and they’re high enough up the corporate ladder that allowances will be considered. If you use a hardware token, someone will break it at a critical moment – or the USB token won’t work with their new whizz bang device.

And once you begin implementation, your organization won’t go from zero to 100% compliant immediately – in addition to dealing with the outliers, you’ll need a transition plan while implementation is underway.

Documented policies and procedures will need to be present – create these as you go, it will be a less onerous task than after the fact. In the case of our verbal challenge and response for a wire transfer example, where will those procedures be kept and how will they be protected – they should be safe from easy compromise, but not invalidate the solution when the primary person is out of the office?

Then there’s the issue of critical software that may need to be externally facing, but doesn’t support MFA. What do you do when the developers cannot implement this in a manner to protect your company? “The program wouldn’t do it” will be of little comfort when you’ve been compromised.

Are the challenges overwhelming? We cannot LET them be, folks. Scroll back up to those numbers – that’s billions with a B. Consider the challenges as things to rise up and meet, in the best way for your organization – rather than mountains that you simply cannot climb.

Questions, comments? I’d love to hear from you – lwallace@microsolved.com, or @TheTokenFemale on Twitter!

Mobile devices…innocent until proven guilty?

How many of us have been on Facebook, and laughed when a friend’s child posts “Child is my favorite!” after their parent left the table with their phone unlocked?

And who has had a friend – or been the friend – who left their phone at the table? Don’t laugh – try being the one who did that WITH the security team. (Guilty…)

Amusing anecdotes? Absolutely. Now, let’s imagine that mobile device is unlocked when it’s left unattended, and contains your corporate data…now what?

That’s where MDM – mobile device management – comes into play. There are a few things to consider when you’re planning your deployment:

  • Who will have access to corporate information on the device?
  • Will you allow people to use personal devices – BYOD – or restrict this to corporate assets?
  • What will you allow, and what do you want to prevent, with device access? Email only? Other resources? Will you allow attachments to be downloaded and stored on the device?
  • How important are remote wipe capabilities – think of the worst case scenario with a disgruntled employee at all levels, with access to your data?
  • What about geolocation capability? Do you want the ability to block access from certain areas of the world – and how easy will it be to fix this when the VP is in Hong Kong, and you’ve blocked APNIC? Do you want to be able to pinpoint the device’s location if it has been lost or stolen?
  • What platforms will you support? Android, iOS, others? Yes, there are other platforms…
  • Consider whether it makes sense to only allow mobile devices to access corporate data via a VPN? Depending on the sensitivity of your data, this may make sense for your scenario.

The majority of MDM vendors will support some or all of the feature set that you desire. Once you’ve weighed out your desired list, and chosen your vendor, there are a number of other factors to look at when considering your actual deployment. A few things to consider:

  • Back to the basics. Passwords – require devices, whether corporate or BYOD, to have a password and to change that password regularly.
  • Encryption. Again, another basic – devices that carry your corporate data should be encrypted.
  • Jailbroken, rooted, and otherwise compromised phones should not be allowed to access corporate data.
  • Require virus/malware protection, particularly for Android devices. Free solutions from well regarded vendors exist, so this is not an onerous requirement for employees.
  • Have valid, documented procedures for geolocation features – whether blocking access or locating devices. Include removal as well as deployment in those procedures – when the VP is back, you will want to remove the access to Hong Kong. And when an employee leaves your company, so should your ability to track their BYOD device.
  • Another item to have documented is your remote wipe or content removal process when a user leaves the company – willingly or not – or when a device is lost or stolen.
  • Decide what you will and will not allow in terms of software on a corporate device. Will you allow users to install Waze? Their favorite game? Define that line in advance, rather than closing the loop later.
  • Regularly audit your configuration, the device compliance, and any exceptions that have been granted. Are there changes that need to be made in light of emerging threats? Are there exceptions that are no longer required?

And remember to take a real vacation occasionally, and put that mobile device down, folks. Those nice people? They’re your family, friends, or others in your life outside of work.

Questions, comments? I’d love to hear from you – lwallace@microsolved.com, or @TheTokenFemale on Twitter!

You backed it up, right?

Yes, folks…we’re back to basics here. Anyone think we’d still be talking about this in 2018? We are…

Our recent incident response work has brought this to the front of my mind. Think for just a minute about a company who has a business vs. technology conflict. They want their backups to be QUICK! So they put their backups on a NAS. Network attached storage.

Key word there – attached. Now, let’s role play that they have been hit by ransomware. They can restore their backups quickly…and now they’ve lost their backups quickly as well. How catastrophic would this be for you?

There are several things to think about when it comes to your backup strategy. First, what do you need to protect against?

  • Natural disasters. Onsite backups are convenient, but not terribly convenient if your whole building burns down. Are you in an earthquake zone? Tornadoes? Hurricanes?What kind of catastrophic happenings could you experience, and how far away do your backups have to be to be protected?
  • Risk from external attackers. Going back to our ransomeware scenario above, what’s the balance between ease of restoring backups vs. protection from harm for your organization?
  • Risk from internal attackers. We all want to trust our sysadmins. What happens if one of them is disgruntled? What safeguards are in place to protect your backups from internal threats?
  • Testing your backups. Periodically perform testing of your backups, both inside and outside of an incident response tabletop. Make sure that your backed up data really IS backed up, and restores in the manner you’d expect. This is a good time to create some baselines on the restore process, as well – what’s your time to restoration if a crisis happens?
  • Hot vs. cold disaster recovery systems. How critical is downtime to your business? If hours means millions, you should have – or seriously consider – a “hot” disaster recovery site to minimize downtime as you pivot over.

Backups are routine, and boring…and when things go well, they should be this way. Prepare yourself for the day things do NOT go well, eh?

What do you think? I’d love to hear what I’ve forgotten – reach out to lwallace@microsolved.com or @TheTokenFemale on Twitter.

Micro Podcast – Office 365

With today’s social engineering threats, every company should be evaluating the configuration and security of their Office 365 presence.
Microsoft has provided many robust feature to secure their Office 365 technology.  Many of these features are not enabled by default or they are not enabled by default or they are not enabled with the optimal settings.
For this reason, we created a podcast about potential issues and remediation strategies for Office 365, enjoy!

Sunshine on a “cloudy” day…

I recently saw an article targeted at non-profits that was a bit frightening. The statement was that small non-profits, and by extension many businesses, could benefit from the ease of deployment of cloud services. The writers presented AWS, Dropbox, DocuSign, et. al. as a great way to increase your infrastructure with very little staff.

While the writers were not wrong….they were not entirely correct, either. It’s incredibly easy and can be cost effective to use a cloud based infrastructure. However, when things go wrong, they can go REALLY wrong. In February of 2018, Fedex had a misconfigured S3 bucket that exposed a preponderance of customer data. That’s simply the first of many notable breaches that have occurred so far in 2018, and the list grows as you travel back in time. Accenture, Time Warner and Uber are a few of the big names with AWS security issues in 2017.

So, if the big guys who have a staff can’t get it right, what can you do? A few things to consider:

  • What, specifically, are you deploying to the cloud? A static website carries less business risk than an application that contains or transfers client data.
  • What are the risks associated with the cloud deployment? Type of data, does it contain PII, etc.? What is the business impact if this data were to be compromised?
  • Are there any regulatory guidelines for your industry that could affect cloud deployment of data?
  • Have you done your due diligence on cloud security in general? The Cloud Security Alliance has a lot of good resources available for best practices. Adam from MSI wrote a good article on some of the permissions issues recently, as well.
  • What resources do you have or can you leverage to make sure that your deployment is secure? If you don’t have internal resources, consider leveraging an external resource like MSI to assist.

Remember – just because you can, doesn’t always mean you should. But cloud infrastructure can be a great resource if you handle it properly.

Questions, comments? I’d love to hear from you. I can be reached at lwallace@microsolved.com, or on Twitter @TheTokenFemale.

 

I’m running out of Post-Its to write down my passwords

We all know to use non-dictionary, complex passwords for our email or online banking or online shopping accounts; whether we put that into practice is another issue. Even less in practice is, using a different password for each of our accounts; that is, never use the same password twice.

Why? The online gaming site that you logon to crush candy may not be as prudent in its security as the financial advisor site that is managing your 401K. The gaming site may store your password in cleartext in their database, or use a weak encryption algorithm. They may not be subject to regulations and policies that require them to have a regular vulnerability assessment. Using the same password for both sites will place either of your accounts vulnerable and at risk.

If a breach occurs and a site’s user data and passwords are unscrambled – as with 3.3 million users of a popular gaming site (article here) – then the hacker can try the discovered password on the user’s other accounts – email, bank, company site logon. And if the user uses the same password across the board, bingo.

You might think unlikely, improbable – how will the hacker know which website to try the discovered credentials? If the email harvested from the gaming site is myemailaddress@gmail.com, they could try the credentials to log into gmail. If the email is @mycompany.com, the hacker would look for a login portal into mycompany.com. The attacker could look for social media accounts registered with that email address. Or any other website that may have an account registered with that email address. The last estimate in 2017 is that there are over 300 million Amazon.com users. The attacker could try the discovered credentials on this popular site; if your favorite password is your birthdate – 12250000 – and you use it for all your logons, the attacker would be on an Amazon shopping spree as you read this blog.

This cross-site password use is not a security issue only through an online data breach; you may have misplaced your trust and shared your password, or entered your credentials on someone else’s computer that had a key logger or you accidentally saved your logon, or browsed the internet using an open wireless hotspot where someone was sniffing the traffic, or through any other instance that your password finds its way to the wrong eyes.

OK, so I need a different password for each different account that I have. I’m gonna need a bigger keyboard to stick all the Post-It notes with the passwords to every account I have underneath it. Or, maybe I could use a password manager.

A password manager is a database program that you can use to store information for each of your online accounts, website, username, password, security questions, etc. They are encrypted, requiring one master password to unlock its contents, all your saved passwords; “Ash nazg durbatulûk” – one ring to rule them all.

Remembering one long, strong, complex, impossible-to-brute-force-or-guess password, you can then gain access to all your other impossible to guess passwords. Almost all password managers also have a feature to generate random, complex passwords that you can use for each of your accounts.

There are many password managers out there, some commercial paid-for programs, some free open-source, with varying features. Some store your data in the cloud, some fill-in the login form automatically in the browser with your account credentials, some you can copy and paste the credentials from the program and the data in the clipboard is erased after a specified time period… You should choose a password manager that is both secure and usable.

Secure in that the encryption used to store the saved credentials and data is impossible to crack. Research what level of encryption your organization requires data to be stored with. When using the password manager, is the data self contained or is it exposed or available for use to other programs, and how. Does the password manager program run in secure memory space or written to a pagefile or swap memory that can be dumped by an attacker.

The password manager should be usable so that the user will be more likely to use it on a daily basis. If it slows down the user too much, it will be ignored and old habits die hard, the user will revert to poor password use behaviors.

An example real-world use of a password manager: Desktop and mobile versions of an open-source password manager can be installed on the Mac, Windows, Linux, Android and iOS operating systems with the one database file containing the credentials data saved in a cloud service. The user can access, view and edit the credentials from any of the devices with the installed program.

Password managers can be an an essential tool in securing your credentials. Do your research; research specifications, read reviews, compare functionality and usability. Also look up which managers have had bugs or vulnerabilities, how quick were the patches released, how was the vendor’s response to the flaws.

Using the same password for even only 2 websites should be a no-no. And forget trying to remember unique passwords to over 20 online accounts (recent research found the average US user has 130 online accounts). Plus, many sites force you to change passwords (rightfully so) on a regular basis. What is my current password to xyz.com that I last logged on 18 months ago?

Password managers can help you use a unique, strong password for each account. A data breach at one website (which seems to be reported on a weekly basis now) should not force you to change your password for any other websites. But protect that ONE master password. It is the one ring that rules them all.

Resources:
https://expandedramblings.com/index.php/amazon-statistics/
https://blog.dashlane.com/infographic-online-overload-its-worse-than-you-thought/

Enter the game master….disaster recovery tabletops!

I snagged this line from the most excellent Lesley Carhart the other day, and it’s been resonating every since.

“You put your important stuff in a fire safe, have fire drills, maintain fire insurance, and install smoke detectors even though your building doesn’t burn down every year.”

When’s the last time you got out your business continuity/disaster recovery plan, dusted it off, and actually READ it? You have one, so you can check that compliance box…but is it a living document?

It should be.

All of the box checking in the world isn’t going to help you if Step #2 of the plan says to notify Fred in Operations…and Fred retired in 2011. Step #3 is to contact Jason in Physical Security to discuss placement of security resources…and Jason has changed his cell phone number three times since your document was written.

I’ve also seen a disaster recovery plan, fairly recently, that discussed the retrieval and handling of some backup….floppy disks. That’s current and up-do-date?

Now, I am an active tabletop gamer. Once a week I get together with like-minded people to roll the dice and play various board games.

For checking the validity of your disaster recovery plan there is an excellent analog to the tabletop gaming world:

Tabletop DR exercises!

Get BACK here….I see you in the third row, trying to sneak out. I’ll admit, I LOVE doing tabletops. Hello? I get to play game master, throw in all kinds of random real life events, and help people in the process – that’s the trifecta of awesome, right there. If it’s a really good day, I get to use dice, as well!

The bare minimum requirements for an effective tabletop:

  • A copy of  your most recent DR/BC plan
  • Your staff – preferably cooperative. Buy ’em a pizza or three, will you? The good kind. Not the cheap ones.
  • An observer. This person’s job is to review your plan in advance, and observe the tabletop exercise while taking notes. They will note WHAT happens, and what actions your team takes during the exercise. This role is silent, but detail oriented.
  • And the game master. The game master will present the scenario to the team. They will interact with the team during the exercise, and will also be the one who generates the random events that may throw the plan off track. It’s always shocking to me how many people would rather be the observer….to me, game master is where the fun is.

Your scenario, and the random event happenings, should fit your business. I tend to collect these for fun….and class them accordingly. A random happening where all credit card processing is doubling due to an error in the point of sale process is perfect for a retail establishment…but an attorney’s office is going to look at me like I have three heads.

Once the exercise is over, the game master and observer should go over all notes, and generate a report. What did the team do well, what fell off track, what updates does the plan need, and what is missing from the plan entirely?

Get the team together again. Buy ’em donuts – again, the good ones. Good coffee. Or lunch. Never underestimate the power of decent food on technical resources.

Try to start on a high note, and end on a high note. Make plans, as you review – what are the action items, and who owns them? When and how will the updates be done? When will you reconvene to review the updates and make sure they’re clear and correct?

Do this, do it regularly, and do NOT punish for the outcome. It’s an exercise in improvement, always…not something that your staff should dread.

Have a great DR exercise story? Have a REALLY great random event for my collection? I’d love to hear it – reach out. I’m on Twitter @TheTokenFemale, or lwallace@microsolved.com

The hotel wifi is encrypted, it’s all good…No?

One of the modern amenities we always look for when booking a hotel room is that it has wifi. However, there are considerations and issues.

When using the hotel wireless network, you are a part of a network with many hundreds of other hotel guests. Innocent and anonymous, family, corporate, hotel guests. And possibly hackers and generally anyone up to no good. They could potentially snoop and view your unencrypted browsing activity. They could scan your laptop and leverage an existing vulnerability.

Traveling from one hotel to another, it can be tedious to enter the hotel wifi passcode to your 10 wireless devices to get connected each time you book into a new hotel (your devices, your spouse’s, your kids’).

You may think the hotel wifi is encrypted because you had to enter a passcode to get connected, but that is not necessarily true. The wireless network may simply require you to login using your room number and last name in order to be authorized to get connected, but that does not necessarily mean the connection is encrypted.

You could use a VPN to encrypt all your internet activity, but you still have to set up all your devices to connect to the hotel wifi first. And you need to have a VPN subscription/setup.

So, how can we secure our wireless connectivity to the hotel wireless network a little bit more?

One of the easiest solutions is to use a travel router. They range in cost from $30 to several hundred. They could be as small as a matchbox or a pack of cards. They could have all the features of a home router, and more. They can be setup as a router, a bridge, a wireless repeater, an access point, a firewall; some even have a SIM card slot so that you can connect to a cellular network and have multiple devices share the internet connection. Others can be setup as a file server or even have a battery, so it can be a free-standing device with no cable attachments.

On a recent multi city trip, I brought along one of these – a RAVPower FileHub Plus, reviewed in this article. I’d set it up before traveling into bridge mode, with my own non-broadcasting SSID with WPA2 encryption. I connected my laptop, phone and tablet to it, and saved the wireless connection details on each device.

After checking into each hotel, I’d connect my laptop or tablet to the router device, and setup its WAN connection – if I connect the device to the hotel room Ethernet, then there’s no need for this step. Otherwise, I would setup the device to connect its WAN to the hotel wireless. Then immediately, all my other devices would have internet connectivity, through my own router, encrypted.

If the hotel wireless network requires a login first, like you have to enter your room number and name, you would do that once, from a browser on any of the devices, then all the other devices would immediately have internet access. Easy. Secured. (Well, as secure as WPA2 can be.)

Connecting to a hotel wireless connection has some considerations – it may not be encrypted and you are connecting to a network where your device is easily visible to all several hundred others. Take some simple precautionary steps to create an additional layer of security around your devices.

Be safe…

Phishing URLs

How many of us inspect a link before we actually click on it? Be honest now, how many hover your mouse over the link and identify the destination in the status bar or popup, before you actually click? If the link is from a trusted site, say in the middle of a CNN article, very likely you don’t. If it’s a link in an email from your colleague, maybe. And even then, how closely do you look?

In many of MicroSolved’s social engineering exercises, alright, authorized phishing campaigns, creating fake links that appear valid is a tried and true method. To make an email look like it’s from John Glenn, a very familiar name recognized as an American hero, it takes 2 minutes to create an email address JohnGlemn@gmail.com. Or BilllyCrystal@gmail.com. Alright, how many of you actually caught the 3 lower case L’s in Billly? And the misspelling of Glemn in the email address?

Same thing with domains. Not to pick on this domain but why is MICRPSOFT.COM registered? Don’t browse to that domain, it gets forwarded to a suspicious link – which proves the point. An internet search for the string “MICRPSOFT” comes up with nothing for that string, all results are for “MICROSOFT.”

It’s a common technique referred to as URL hijacking or Typosquatting. It counts on the user not paying attention to what they’re typing into the browser address bar. Or it counts on the user not noticing the misspelling even if they were hovering the mouse over a link before they clicked.

Many of you have heard of the Equifax breach earlier this year. They registered and set up a domain for the public – equifaxsecurity2017.com. At this site, you could get more information, as well as enter your SSN (last few digits) to find out if your personal data had been part of the breach. However, a security professional registered securityequifax2017.com – and many legitimate sites actually directed traffic to this fake domain instead. Fortunately, it wasn’t anyone malicious, but someone who wanted to prove the point – and did – that these domain names can easily be abused. Equifax itself tweeted the fake domain, thinking it was their own.

So what are we to do? It’s easy to say, just be vigilant, be cautious, be on the lookout. There are tools, browser plugins, background running processes that can check links or clicks. But here’s an anecdote on relying on an “automated” tool that does things for us. I was pulled over at dusk couple weeks ago (wasn’t night yet, could still see the setting sun), driving my wife’s car that did NOT have daytime running lights. My car does. I have so heavily relied on this automated feature that when I was in a different environment that did not have it, I forgot to check the basics – it’s getting dark, are my lights on? Incidentally, the officer just gave me a warning.

Recommendation is, be vigilant, be cautious, be on the lookout. Check those links or email addresses. Check the spelling. Type in the link instead of clicking on it. Copy the link and paste it into the browser address bar, and verify before pressing Enter to navigate to it.

It’s a jungle out there. Be safe…