You may remember the confusing external emails we all received at the first of October. One email was from McLean & Company asking UT faculty/staff to complete a survey about the COVID-19 pandemic. This survey did not show who at UT was asking the outside company to conduct the survey, so it did appear to be spam.

The other email was even more questionable because the external mail, from Lincoln Financial Group, was sent to UT faculty/staff giving people an opportunity to sign up for long-term disability. The content of the email included instructions for logging into their site, which included using your Social Security Number and birthdate as your user name and password. This email also followed a similar email from UT System Office of Finance, giving information about enrollment in the LFG disability insurance. The emails were not very similar and the internal email did not ask for your SSN or birthdate.

First, I must thank you all for being so attentive to the things that stand out as spam. Everyone at the Institute does such a great job asking about things before clicking and I appreciate that more than I can say! That week was a tough because the signs were there pointing to more external emails to be deleted. However, these were not spam.

I promised I would have conversations with my CISO colleagues to try to find a better way to send emails to our employees who are keen on doing the right thing, but are being confused by the messages that go against what the CISOs preach. I started with the System CISO, since these emails pertained to UTSA. He asked what I would recommend and he took those recommendations to those who send these kinds of emails via external sources. They have agreed to work on the following:

• If UTSA wants to have an external sender working on a System-wide collaboration, they will work with the external vendor to either brand the emails so you can tell, or (my favorite), have the vendor let the requesting party send the email so it is not an external email.
• If any login information is included in the email, they will work with the vendor to find a better first-time login that using the SSN.
• And they will refrain from sending both internal and external messages. I mentioned that there was nothing in the internal email that raised questions, so maybe they will just have the internal emails next time. Keep in mind that you cannot always trust an internal email, as accounts do get compromised or spoofed, but think of who the sender supposedly is and what they are asking.

As for any similar emails to those above that may need to come from an external source dealing with the Institute, please follow the recommendations above. However, if none of these will work for you, let me know and we can discuss other alternatives. And, as always, I am open to any suggestions you may have about external emails or anything else that is related to IT Security.

I thank you all again for your commitment to protecting the Institute, the University, and yourself!

Sandy