The move to work from home brings increased security risks. Carol discusses what can be done to detect and defend against these new risks.
With the onslaught of the Coronavirus, many organizations have been forced to move their employees into a work-from-home status—often with little or no notice. From a system-security perspective, working from home is inherently less secure than working within the confines of a local network. And this risk is magnified by the volume of employees working from home, the lack of a formal work-from-home policy, and the rapidity with which this move had to be made.
In this article, I’m going to discuss the increased risks and describe some steps you can take to reduce the risk to your organization.
The Bad Get Worse
While I definitely know of ways that people are stepping up to help one another during this time (to name just two, my 16-year-old great-niece, Ava, is helping the senior citizens at her church by shopping for their groceries, and my church is reaching out to aid the homeless in Seattle by giving them a way to “shelter in place”), the stories are not always so encouraging. A headline in one of the security newsletters I read was “The Lowest Get Lower.” The article described the new phishing scams that are playing on the fears of the Coronavirus. Over the past few years, phishing has become more and more of an issue, but right now it’s as virulent as the Coronavirus itself. For example, a URL appearing to be the Johns Hopkins COVID-19 dashboard is actually malware being passed around via phishing schemes. Another scam going around appears to be a company allowing you to do work from home and help distribute funds to those in need. It’s a spoofed site based on a legitimate organization helping those in need, but it collects the funds and then, rather than distribute them to those in need, the worker unknowingly routes them to offshore accounts. Ransomware is also on the rise. Criminals are targeting routers commonly found in homes and small businesses to reroute domains to spooled domains where the pages are full of links behind which are ransomware and other malware.
How do we combat this? By education. We must remind our friends, family, and employees to be extra diligent in our web surfing and be cautious about what we click on in email and on websites. Also, remind them to change their home router passwords to be something other than the default and to enable auto-updates.
This situation is exacerbated because you may not have as much control over your endpoints (your employees’ workstations) as you usually do. For example, your anti-virus and Windows updates may not be getting regular updates if the employee isn’t connected to your organization’s VPN when the updates are typically pushed out. If you have dashboards to see which endpoints have been updated, you’ll want to be extra vigilant and may need to reach out to employees to get their workstations updated. In addition, some employees may be using their own equipment; in that case, you may have no control over what AV software is running and/or when it’s updated.
Again….education is key!
Business Email Compromise (BEC)
Business email compromise was already on the rise, but it will likely spread as fast as the virus appears to be spreading. One example of BEC is when a hacker breaks into an email account (typically via stolen credentials), watches the conversations going on, and at an appropriate time, inserts themselves into the conversation. When the account is someone in finance, they will insert themselves at the time an invoice is typically sent from a vendor. Or they will claim that an invoice hasn’t been paid. But the routing code for the bank on the invoice is theirs rather than the vendor’s. The organization pays the invoice, and the attacker gets the payment. Unless the organization catches the error within the first 24 hours, the payment has gone to banks outside of the country and the organization has lost their money. The FBI estimates that U.S. organizations lost $1.77 billion to BEC in 2019.
Why do I think BEC is going to rise with the rise in working from home? Because when you’re in the office and something looks odd or doesn’t seem right, it’s quite easy to shout over the cube or walk down the hall and ask a colleague for a second opinion. But when you’re working from home, a colleague may not be available online when you need them, and, depending on the technologies you’re using, it may not be easy to have them look at or double-check what you’ve been sent. In other words, I think workers will be more apt to just approve invoices or move them through the process rather than stopping them for further analysis as they would have when working in the office.
The way to combat BEC is, again, education. This is a new phenomenon to many organizations. And no organization is immune. I’ve seen organizations with a huge focus on security get hit with BEC. That’s because the email infiltration wasn’t through that organization; it was through their vendor’s. Education for these employees is a must!
The Tempted Act on Their Temptation
I attended a breach and fraud workshop in NYC a couple of years ago and learned that many employees are tempted to commit fraud but won’t for fear of getting caught. The speaker said that, in their educational institution, simply mounting a non-working camera in the room holding the supply cabinets significantly reduced the office supplies that typically disappeared prior to the start of the school year. Now obviously the theft of school supplies is not going to increase in this work-from-home scenario. However, what other things might an employee be tempted to take? Wouldn’t it be much easier to insert a USB and download the company’s customer list so that, as a salesperson, you’ll be able to take it with you if you lose your job? Or, if an employee is feeling financial pressure, how easy would it be to download the HR or healthcare information database and sell it on the dark web? If your organization hasn’t implemented any restrictions on what can be downloaded, now is the time these actions should occur. Desperate times lead to desperate actions. To think users can’t figure out how to download data from IBM i is very naïve. A simple google search is all it takes.
How do we combat this issue? The right way to fix the issue is to tighten your security settings so even if a user attempts to download a file, they won’t have sufficient authority to do so. Unfortunately, many or perhaps, most of you aren’t able to do this type of significant change at this time. So do you just give up? No, you perform increased monitoring at your firewall, SIEM and IBM i and if you’re using a Data Loss Prevention (DLP) solution, you may want to tighten down your rules a bit.
Specific Recommendations for IBM i
I’ve been talking about some general recommendations. Now let’s talk about specifically what can be done for IBM i.
Now is the time to clean up those items that you’ve been meaning to for a long time. For example, remove inactive profiles from the system. At this point in time, when attackers are attempting every method possible to infiltrate organizations, why would you want to keep around any profile that is no longer in use, leaving the potential for it to be abused? Please, get rid of inactive profiles! If you absolutely must keep a profile on the system, then, in addition to setting the status to *DISABLED (which is the traditional action to take), I suggest you set the password to *NONE and remove all special authorities as well as the group profile assignments. Basically, make it such that if the profile is reenabled, minimal damage could be done if the profile is attempted to be used.
Another area that needs to be addressed is profiles with a default password. Now if a profile happens to be a service account, then you obviously will have to determine where all of the connections are coming from before changing the password. Nevertheless, the first password an attacker will try will be a default password. If regular or non-service accounts have a default password, the password should be set to expired so it will have to be changed with the next signon.
Finally, another issue that needs to be addressed is that of read/write shares to root (/). I wrote earlier about the increased phishing attacks. The result of a successful phish is usually the delivery of malware—and most often ransomware. If that user is connected to a read/write share to root, the malware will affect the PC and then march right through the drives attached to the PC. If that drive is IBM i, it will infect everything it has authority to. If the share is a read/write share to root, it has the potential to infect your entire IBM i system. Once you’ve gotten shares to root addressed, I suggest that you review all of the shares that have been defined and, once again, remove shares not in use. And any read/write share that can be a read-only share should be modified to reduce the risk of the objects in that path being affected by malware.
For additional steps you can take to reduce the risk of your IBM i being affected by viruses, check out my previous article “Tips for Avoiding Malware on IBM i.”
Most organizations have IBM i auditing configured. But many organizations are not proactive about reviewing the actions logged in the audit journal. Now’s the time to change that behavior. This is especially true if you have not built up a strong security defense (in other words, have not implemented object-level security and/or implemented rules in exit points preventing the downloading of data.) Attackers are working overtime to infiltrate organizations. If you don’t have defenses in place to prevent them, then you have to detect them. So what should you be looking for? I suggest the following:
- Unexpected changes to system values, especially changes to auditing settings, maximum sign-on attempts, and the password composition rules
- Authority changes to critical files
- Creation of or changes to user profiles by unknown users or by known users but from unexpected IP addresses (indicating the user’s credentials may have been compromised)
- Invalid sign-on attempts
- Specifically, I’d look for widespread invalid passwords as an indication of someone (either external or internal) attempting to guess a valid profile/password combination. Remember, internal users know the profile naming convention, so all they have to do is guess a valid password and they’re on the system with a profile that’s not their own.
- I’d also look for attempts where the user name attempted is either root or admin and the attempt is coming from an external address or an internal address other than the server that runs your internal network scans. When coming from an external IP address, this is a definite indication that your system has somehow become directly accessible from the internet. (See my article “Has My IBM i Been Breached?” for additional details.)
- Finally, I’d look for attempts to log on with the IBM-supplied profiles QSECOFR, QSRV, QSRVBAS, QPGMR, QSYSOPR, and QUSER since these are well-documented profiles.
- This brings up my recommendation to set QSECOFR to status of *DISABLED to protect it from abuse and to set the other profiles to status of *NONE (their shipped value.)
- Activity of QSECOFR
- If you don’t have *JOBDTA or *JOBBAS specified for QAUDLVL consider adding it at the user level using the Change User Auditing (CHGUSRAUD) command to log the commands run by QSECOFR. This allows you to review the use of QSECOFR for interactive sign-on.
If you have an exit point solution such as Powertech’s Exit Point Manager, now’s the time to use it! My preference would be to add rules so that users without a business need do not have the ability to download and/or upload data. That said, if you don’t have rules in place now, you may be prevented from adding them at this time. But you can still review the activity. If you haven’t been reviewing the activity prior to this time, you may want to go back in time to determine what is “normal” activity. Then, start meticulously reviewing the activity, paying special attention to spot abnormal activity—that is, users downloading files that they don’t normally download or profiles logged against servers (such as FTP) that don’t normally use FTP.
If you aren’t already sending your information to your SIEM, consider starting that now so that there’s a complete picture of the activity occurring in your network. For suggestions, see my article “What IBM I Information Should I Be Sending to My SIEM?”
Review Your TCP/IP Configuration
Be sure to review the auto-start values of your TCP/IP servers. If you aren’t using the interface, the server shouldn’t be started. Interfaces such as REXEC are often started but rarely used and pose a vulnerability to the system. For the list of servers used by Access Client Solutions (ACS) see this. And the ports used by each are here.
We’re going to get through this. And when we get to the other side and everyone’s back in the office, I’m sure management will review what went well and what could be done in case (God forbid) something similar happens again. During this review process, I encourage you to bring up the need to tighten your security posture as well as increase security awareness for all employees. If you have not implemented object-level security, you need to consider that project. If you haven’t implemented exit point programs (if for no other reason than increased visibility into the activity on your systems), consider it now. If you aren’t auditing on your IBM i, configure it. If you are not sending information to your SIEM, you’ve got a huge hole in the view of what’s going on within your organization, so close that gap and start sending it your IBM i audit journal information. Please do not ignore this opportunity to strengthen your security posture.
A Special Thanks
At this time, I think we need to step back and evaluate who and what is important to us. To me, my family is everything. I’d like to give a special shout-out and thanks to my doctor brother and my nieces and nephews—a nurse practitioner, a registered nurse, an occupational therapist, two physical therapists, and a fire captain. They are on the front lines in treating the ill and the recovering. I am thankful for you and for what you do. We also need to take the time to thank the grocery store workers, delivery people, and other workers who continue to go to work to give us the ability to get food and packages. I encourage you to let these people know how much you appreciate them! Together, we’ll get through this!