IT Security Refresh: Practical Tips for a Good Foundation

I’ve stayed away from IT security for a long time. It has seemed to me to be like standing next to a dike, poking fingers in as many holes as I can, eventually running out of fingers. Then I look around and see malware coming through more leaky holes, then looking up to see malware sloshing over the top. Is it really possible to provide reasonable IT security to an organization? Are there practical things enterprises can and should be doing?

 

NetCraftsmen co-worker John Cavanaugh recently pulled me in to assist with a security assessment. I was skeptical at first, since IT security seemed so futile. However, he shared some excellent material about how to protect corporate IT infrastructure. It turns out to be easier than I expected to build a solid security foundation. More importantly, there is factual evidence to indicate that the foundational steps actually work.

 

Ransomware is the most common malware, often sent in phishing emails that get someone to click though to a Web page that infects the user’s computer. The malware will then use horizontal propagation to distribute itself within an organization. It stays dormant for a few days to allow the encryption to spread, then wakes up and encrypts files. The encrypted data can be unencrypted by paying a ransom, typically in Bitcoin, to the encryption key holder. Ransomware authors have generally been good about providing the keys, otherwise their victims would have no reason to pay the ransoms.

 

Businesses have frequently been paying ransomware fees as the easiest approach to returning to business. But that only encourages more ransomware. Even if an organization has paid the ransomware fee, it still needs to spend on making sure that the IT systems aren’t vulnerable to a repeat attack. Some organizations have been hit multiple times because they continue with a business-as-usual approach. Other organizations have used system backups to return to business, although with a loss of some data since the last good backup.

 

Macros in Word documents propagate one version of ransomware. Infections spread when users share those documents, regardless of the sharing mechanism. Storing documents in a cloud system doesn’t prevent such malware unless the cloud storage system includes additional security scanning measures.

 

Ransomware that encrypts large shared document repositories are particularly painful. The same goes for backup partitions. If the backup repository is read/write accessible all the time, the ransomware can encrypt the old backups, rendering them useless for a recovery (read related article, “How Ransomware is Beating Your Backup”).

 

The National Security Agency’s cybersecurity unit has identified three basic security functions that would have prevented a substantial percentage of cyber incidents that they they’ve experienced (read related article, “NSA: We have not responded to a zero-day in two years…”). That’s a pretty darn good foundation upon which to build.

 

The city of Atlanta could have protected itself from its 2018 cyberattack using MFA. The ransomware easily propagated internally by using a brute-force password guessing mechanism. MFA relies on two or more secrets to gain access to an IT system. The typical mechanism uses two factors: something the user knows and something the user possesses. A password is frequently the factor that the user knows and a security pass key token generates a numeric pass key that’s valid for only a minute or two. Another secondary factor is to send a numeric code via an SMS message to the user’s cell phone. The user must enter the numeric code as part of the two-step login process. The Atlanta ransomware would have failed the second step of the login process and been unable to propagate.

 

The next function is role-based access, which prevents users from performing functions that aren’t part of their roles in the organization. Only IT administrators, not computer users, should be allowed to modify computer system files and privileges. There may also need to be an additional authentication step for system administrators to perform system modification functions.

 

Attempts by a non-administrator to modify system settings should be automatically logged to a security server for reporting and tracking of intrusion attempts. This is much like an early warning system that malware is knocking on the door and where it originates. IT security professionals can then take defensive measures.

 

White-listing applications is similar to role-based access, only allowing IT systems to communicate with other IT systems that are necessary for performing their functions. In a three-tier (Web, application, and database server) application model, the Web server should only communicate with the application server and with the external user, perhaps via a proxy and/or load balancer. In turn, the application server should only be able to communicate upstream with the Web tier servers and downstream with the database tier servers. Finally, the database tier servers should only be able to communicate upstream with the application tier servers and perhaps downstream with a back-end storage system. Each of these systems may also need to communicate with other systems like Domain Name System servers or be monitored by network management systems.

 

Unfortunately, many application vendors can’t tell what protocols (TCP or UDP) and ports are in use. Some application vendors just request that all communications be left open, but that’s not a good idea. Fortunately, you can use tools like NetFlow to determine what communications is happening. You should be prepared to monitor some applications for longer periods of time to catch periodic activity, like monthly and quarterly financial reporting. You should investigate tools that automatically build access control lists that you can use to allow the desired connectivity and block everything else.

 

It’s important that you review the communications that is occurring between systems, just in case your IT infrastructure is already infected and is trying to propagate horizontally. I know that this isn’t generally possible for organizations that have hundreds of applications. However, by using automation and exception reporting, combined with other foundational steps, constructing basic white-listing security is possible.

 

From this foundation, you can take many additional steps. I’ll look at recommendations for next steps in my next post.