Network Security Is An Application Layer Issue pt 3

Part 3 of a 3 part series

In Part 1 and Part 2 of this series, we discussed the impact and risks associated with some fairly common software development practices. For today’s topic however we will be looking beyond internally developed software, and focusing on software from outside the organization. It is frequently a threat that is just as dire, but for which there is always significant “push back” from users, not just in IT but the business as well. There is pushback because we will be discussing maintaining rigid control over the installation of software to any network device.

Returning to the days of presenting security issues as a guest lecturer to graduate level students, the below image is one of my all-time favorites. It is a screen shot of an actual user’s Internet Explorer. Savvy readers will note the dated versions of Windows and Explorer, and some may even note the dated versions of some of the malware (the screenshot is over 10 years old). The threat really has been around that long. And even this long in the tooth, it is essentially the same.

First, note the actual window left for the browser to display a web page. It is roughly 9% of the available landscape, at the bottom right. Secondly imagine the performance issues this user experienced with roughly 25 browser re-directs vying for supremacy, the animations (including the juggling gorilla), various “news feeds and weather updates, and who knows what else all running in the background. The uninformed will tell you this is a Microsoft and IE problem, that other platforms or other browsers are not susceptible to this issue. I can tell you categorically that opinion is not accurate. Plug-Ins, BHOs, Tools, Add-Ons and Extensions exist for all of the know browsers.

And the basic premise goes something like this:

• Offer a “free” gadget, widget or gizmo. Make it as fun, cheesy or “useful” as possible.
• Embed your choice of key loggers, redirects, hijacks, Trojans, port sniffers whatever you like.
• Put the gadget out on the internet, any of the free hosting sites will do. (point to it with tons of cheap advertising, or even redirects from other such gizmos, or not depending on your budget, and patience.)
• Set up a server to collect the incoming data.

And this is just for the lazy ones who don’t want to bother with their own deployment package, or full .exe. For the enthusiastic and adventurous, the sky is literally the limit. What the gray market programmer creates, and the data collected is only limited by their imagination. And it runs the gamut from simple HTTP redirects to Key Logging usernames and passwords to financial institutions and sending them to Russia (a known ring of bandits that operate with impunity). Or, depending on the damage intended and the patience of the perpetrators, the “King” of all malware attacks is still stuxnet. Depending on your political views and social beliefs you may have cheered the success or not, but stuxnet was malware.

And just to absolve any passive readers who think this is only a “freeware” problem, and a strict policy will solve it. Let’s go back 15+ years. While doing some work for a mortgage company, I noticed some odd traffic on the network. After a discussion with my network security guy (a real hacker that had gone “white hat”) that there was no valid reason for the traffic, we decompiled and decrypted a mortgage application processing app. What we found was a beacon device that was sending server names, IP addresses, admin usernames and passwords to the database to an unknown IP address. This was a small cheap software package that had less than 1% of the market share for mortgage application software, but still, it was commercially available and apparently completely legitimate software. And yet, it was feeding security information to persons unknown.

Currently, well known vendors of software, hardware and tools routinely add unsolicited software, search providers and logging to basic installs by default. Requiring a preselected checkbox to be unchecked to avoid it. And some do not permit the installation of the primary software without the add-ons. Additionally, the EULA for most software will explicitly say they are collecting and using data at their discretion, and will change their collection and use practices at their sole discretion. Many of these now are flagged by many of the more comprehensive malware detection programs.

As such, all software must be fully vetted and determined to not be a security threat before it is permitted on a network device. This would include a comprehensive assessment of what the installer installs, any information collected and actually reading the EULA.

The simple solution

• All devices should be imaged from a known source (preferably one created by the organization).
• Admin permissions and the ability to install software, AND to edit/modify the registry should be denied.*
• All software permitted on network devices must be vetted an approved by IT Security or if no such group exists then by Network Engineering.
• All ad hoc requests for software must be installed by the Network Engineering group after being vetted for security threats. (never by granting the end user “temporary permissions”)
• Routine scans in addition to standard virus / threat detection should be run to check for unauthorized software.

*note – There will always be a small set of users that will need to have accounts that have the ability to install and edit the registry, Server Engineering, Desktop support, some development etc. These can be managed separately on an as needed basis.

Ask any C-level executive if they let random strangers off the street into strategy meetings and product discussions or if they publish banking and accounting information to public bulletin boards. If the organization is not following the above steps, or something substantially similar, and the executive’s answer is “Of course not!” just smile and say “Wanna bet?”