Educause Security Discussion mailing list archives
Re: Bagle.j out
From: Jack Suess <jack () UMBC EDU>
Date: Wed, 3 Mar 2004 06:46:43 -0500
What I will probably look at following the suggestion in the Educuause/Internet2 Effective Security Practices Guide http://www.educause.edu/security/guide/VirusandIntrusionDetection.asp and require my mail administrators to rename .exe and .zip attachments to something that can't be auto-opened. This allows people to still transport these but they have to go through a extra step of saving these as a different name and opening the application to read these. Usually those steps provide the "thinking pause" necessary to realize what is legit or not. Using the Effective Practices guide in this way helps provide additional credibility for changes such as this. bradley, As i read your message I can envision going to my president and saying that in the "name of security" we should be replacing all the computers with SunRay's and eliminating email attachments. I can trumphet the security enhancements but the reality is institutional productivity would go down dramatically (though I think SunRay type devices have many great applications). Is this what we want? I fear when people in IT propose radical changes that are primarily for OUR benefit we lose credibility with the campus and they stop listening to us, even for more reasonable requests. IT Leaders in higher education need to bring credibility to the table that they understand and support the mission of the campus -- supporting teaching and scholarship while providing the underlying functions to run the business of the university. I feel taking draconian steps, crippling the MUA, banning binary/encrypted files, or blocking attachments essentially mean we've given up and allowed the virus writers to win. I'm going to end on a positive note: * I've seen a huge jump in user awareness. Most people were very suspicious and didn't trust this message. That is a positive sign * Our security team got word out quickly to the campus -- response and handling on our campus has gotten alot better and I sense the same for many other schools as well. jack suess, CIO, UMBC On Wed, 3 Mar 2004, Bradley D. Thornton wrote:
Tuesday, March 2, 2004 10:36:26 PM (-08:00hrs UTC) Hello Jason, On Tuesday, March 2, 2004, 8:08:51 PM, you wrote:Question: has anyone resorted to dropping ZIPs and/or other attachments at your gateways until/unless this storm passes? I mentioned in a meeting that I would be proposing it to my management and received the predictable reaction, i.e., "you can't block ZIPs, we won't be able to do business." Of course I was not deterred but I also haven't been given clearance to block the attachments.The paradigm of email stands to devolve into a more sound policy by stripping attachments from the message. Email wasn't intended as a file transport protocol, and even up till a couple of years ago (when bandwidth was at a premium for most consumers), that was the standard answer that many ISPs would give in response to messages that were filtered or bounced because they exeeded size quotas. Educational institutions had the luxury, to a great extent of not having to concern themselves with managing the size of email messages due to their available bandwidth. As a result, people emerging from these institutions took for granted the convenience of sending large attachments as part of their messages (as time progressed, people didn't even bother to compress the attachments). The common methodologies for distributing files, and packages of files were enacted with schematas such as placing links in the message so the files could be downloaded via HTTP or FTP. Many ISPs and strict corporate environments simply responded with, "Use FTP" or "Don't send attachments in emails." Then there is the "cat out of the bag" scenario - which we are currently dealing with as a matter of policy. We have permitted people to become dependant upon email as a file transport protocol, so to speak, through an implied agreement when we neglected to either educate the user or insist that they not send large messages with attachments. But where are the problems really? 1.) As mentioned above, people take for granted that transporting files via email is perfectly acceptable, and even optimal - it is not, but it does seem to work fine, and the MUAs support it. a.) For those of us who feel that enforcing the correct use of protocols includes automatically stripping attachments from emails with a link to educate the user as to other, and more correct methods of transporting files, this can assist in the short term for limiting the detonation of attachments in emails. i.) users will take the easy road - they will continue to open attachments in their emails, either through naivity or convenience - removing this possibilty means they can't detonate a payload by opening an attachment in their email. ii.) providing links in emails is extremely important, and perhaps more stern measures of encouraging the user to educate themselves or acknowledge their understanding of the relationships between exploits in the form of attachments are in order. iii.) providing links explaining (luring the user by leading them on as to where their attachments may be perhaps?) why they won't get attachments in email releives a significant burden from the MIS department or Help-Desk/Tech Support center - especially if the support framework personnell simply send the same link to them as an explanation by requesting the users email address when they call. The user needs to be empowered, and obliged to empower themselves - they will not do this if not obliged to do so. 2.) Some of the most popular MUAs make it easy to transport files as attachments to emails, and the most popular MUAs, or any exceedingly popular user application for that matter, is a prime target for exploits. a.) In environments where the user can be locked out of any administrative role at the local workstation, solutions exist simply by forcing the user to use an MUA (or any other particular user-level application) that is designated by the administrative staff and decision making channel b.) Another alternative is to cripple the MUA, if possible. i.) this didn't use to be possible with many commercial products, but the current trend in a single logon environment is to bring configuration management of even the local user apps into the purview of the network administration staff. ii.) using this schemata, MUAs can be configured for the desired level of security - such as dissalowing the opening of attachments from within the MUA, therefore requiring the user to 'save' the file to disk where the antivirus software can provide an added layer of protection. 3.) encrypted, compressed files containing payloads with exploits only serves to emphasize that virus/worm containment is a reactive at best, as opposed to proactive technology which by definition evolves in an 'after the fact' manner, with regards to the development and release of exploits. 4.) email is one of the most popular ways to distribute payloads containing exploits - everyone uses email, which is why distributing these payloads in such a manner is so popular. 5.) many environments permit the user to be an administrator in some fashion - at least at the local workstation level. a.) removing the user from any administrative role on the local workstation is ideal under most circumstances. i.) Consideration needs to be given to the selection of antivirus products in such scenarios. Many products do not run as a daemon or service with root priviliges or administrative rights and are therefore precluded from loading and protecting the file system when the user logs on. 6.) many of the problems we face today are a direct result of accommodating executive level employees simply because of their stature (If a VP of sales is allowed to send attachments in emails then eventually his staff of sales reps must also be allowed to do so since he will complain that his staff isn't receiving his spreadsheets, etc.). Once this occurs, a snowball effect ensues, and sound MIS policy decisions are overridden, department by department, by those who desire the shortest path to a given result (The fault/responsibility in this case is that of the MIS department - not the users). a.) decision makers in userland already understand, and are usually indeed receptive to being reminded, that they are not the best authority in determining sound MIS policies. Moreover, the MIS department is often remiss in their responsibility to remind executive-level personnel of this fact, and require compliance from them. i.) it is the responsibility of the MIS department to implement and enforce sound policy decisions enterprise-wide. ii.) it is the responsibility of executive management to implement reasonable budget constraints for the MIS department. iii.) the two are NOT mutually exclusive. 7.) it is virtually impossible to install the most vulnerable of todays operating systems on a network without them being compromised - unless the installation is performed with the workstation being the only machine on the subnet, and shielded behind some form of firewall. Installing an operating system and applying the patches on a populated (even trusted) LAN is insane. a.) patches and security updates should be applied while the machine is not connected to a network, if possible. Otherwise, placing the machine on it's own, packet filtered subnet without any port-forwarding capabilities except for established connections is an alternative i.) one of those little linksys BEFSR-11 boxes, for example, can be conveniently carried in a bag by the technician performing the OS install will provide a relatively secure level of protection until all of the security patches and updates can be installed via an HTTP session initiated update process. ii.) standarizing the footprint of the desktop workstation platform enables the implementation of using 'imaging' methodologies for 'blasting' images onto workstations, including both (patched) OS and applications. Likewise, applications can be 'pushed' across the network and installed/uninstalled on workstations remotely, either by batch processing or by manual intervention of the MIS staff from a remote location. iii.) patches and security updates can be applied as well using a push technology. iiii.) user login scripts also facilitate and support this update technology. 8.) most environments provide disk-based workstations. a.) diskless workstations provide an optimum environment for preventing the corruption of the local filesystem, since it is virtual. i.) there is a cost involved relating to bandwidth with such implementations ii.) Many users protest, since their perception is that they do not have access to all of the features they normall would with a disk-based workstation - this is false. network drives can be protected easier than those on local workstations iii.) if a virus or worm infects the workstation, a simple reboot eliminates the problem. iiii.) access to the network is of paramount importance - availability of service is another cost to be added to the cost of bandwidth management. v.) the cost of bandwidth management and availability of service is offset, to by some variable degree depending upon the technical support personnel framework, by a reduction in the amount of field service calls to the local client site. vi.) the liability involved in managing licensing of legally installed software and software piracy is greatly reduced in such an environment. vii.) most decision makers at the user level, responsible for allocating budget resources for information technology, erroneously and categorically dismiss the idea of ASP driven environments with diskless workstations. 9.) Many educational institutions have four separate types of network users a.) those who are part of a so-called 'main' network, with single user login to a managed, controlled environment through LAN/WAN/VPN. i.) this is probably the second least problematic of all connection types, since it is the most managed, and controlled by the MIS department. ii.) disk-based workstations iii.) diskless workstations b.) those who remote in via RDP, SSH, PCAW, VNC, etc., from a remote and user administered workstation from home or some other uncontrolled access point. i.) less problematic than directly connected, autonomous workstations, but more problematic than dedicated workstations, since there are support related cost issues pertaining to the users ability to the users ability to remote into their trusted remote workstation on the enterprise network. ii.) wherever possible, firewalling policies should be implemented that permit the establishment of: A.) connections only from certain approved, known, and verified IP addresses outside the enterprise network. B.) connections only involving the neccessary protocols, and port numbers required to establish such sessions for the user from their remote workstation to the workstation on the enterprise network C.) obscure port numbers should be used, instead of the standard port numbers for services like RDP, PCAW, VNC, and even SSH, if possible. D.) IPSec tunnels or some other form of "Secure" tunneling protocol should encapsulate the users session if possible, as mentioned in #9-a above. E.) X protcol offerings should NOT escape the edge routers of the enterprise unless they are in a tunnel. c.) Those who are directly connected to some sort of on campus pop through their labs or offices, but not subject to the security and administrative policies and procedures whereby the MIS department can ensure adequate protection at the users local workstation. i.) this is often the most problematic of scenarios, since support for these users is often under the purvue of MIS staff, while at the same time remaining autonomous over the control and administration of their own respective machines. ii.) this scenario is also perhaps the most dangerous, since access to enterprise resources can perhaps be made available through manually mapping out the desired mount or share points by the user. iii.) since the users machine is usually a member of a trusted subnet in the enterprise WAN, containment of network based worms and viruses are especially problematic, due to the limited administrative capabilities that the MIS staff has over the workstation. d.) those who have no theoretical access to network application or server resources, but who nevertheless gain transport access over the enterprise backbone to an Internet - i.e., students in on campus housing, or via dialup. i.) this is typically the most neglected, and overlooked type of connection/user. It is also potentially one of the most dangerous, from the aspect of a "Trusted user exploit". Sound security policies should be in place to protect the network from malicious users that are 'semi-connected' to the enterprise network - even if all they are doing is being authenticated via RADIUS and DHCP in order to provide them with transport over the enterprise backbone. ii.) this is typically the least problematic of all user types also, since students are usually required to be responsible for reading and learning on their own, how to establish their access accounts and use them. iii.) these types of connections should whenever possible, be limited to special subnets which are not routed with other enterprise traffic on the local campus WANs, restricted only to the backbone for Internet access or other publicly accessable services provided by servers in one of the enterprises DMZ areas 10.) Server/routing policy: a.) most commercial providers, and many MIS departments have taken the position that the user is responsible for the health of their machine. That is okay when the MIS department doesn't have to share the burden of cost for re-installing the OS on user workstations or dis-infecting a machine. Many organizations have a server, or backbone group, and a separate workstation support group that are independant of each other both in budget allocation and in departmental management. This doesn't scale well when considering the cost that one department incurs at the expense of the other's shortcuts. Perhaps it is okay for an ISP to defer the responsibility of local workstation health to the user by adopting a policy of pass-through SMTP. After all, the user is paying the ISP to get all of their mail, and perhaps the user has no friends and likes to read spam, or is wise enough not to open mail from windows.patch.com that says to follow install a security patch from Microsoft. In the Campus environment, we may even be able to relegate the student user account for Internet access to this level of self-management. But within departmental entities, not only is a firm security policy required, but the implementation of safeguards are warranted as well at the server level - most notably, wrt SMTP. Whether filtering out email attachments is the correct policyin addtion to providing some other level of filtering protection, is yet another decision to be determined. To wrap it all up, whether zip files are stripped from emails or not, the network is going to remain at risk, and containment of any threats will remain confined to a reactive, rather than proactive policy. Simply enacting this for, "The duration the threat exists" will not suffice, IMNSHO. The choice needs to be made with respect to a long-term policy, but the policy needs to be zealously defended regardless of the decision by any particular institution. Going back and forth with knee-jerk reactions to the latest threat only exacerbates the already expanding budget that an IT department requires, and re-educating the user as to their options when transporting files (either under a new lax policy or again later under a more stringent approach) adds to that exacerbation. I haven't attempted to supply many of my own philosophies as actual suggestions - only where I feel strongly about certain 'holes' in many of the architectures I commonly have to shore up. What I did put on the table I think, is a fair checklist to go over, where one can apply the decision making process by asking how the current dillema applies to any one of the particular scenarios above. Hopefully, by going down the checklist one can arrive confidently in their own personal policy view of any respective, basic institutional architecture. The bottom line is that the user WILL adapt to whatever policy is implemented, and the cost is reduced by sticking with the decision once it has been made. The thing that bothered me the most about Jason's post though, was the reaction he got from the brass: "you can't block ZIPs, we won't be able to do business." I've always been pretty adamant about one thing when developing policy, having come from a DoD background back in the ARPAnet days. The MIS department needs to dicate a sound policy, implement it and enforce it - the user needs to be educated "How" to do business within the constraints of that policy - and the policy should not be dictated by ignorance on the part of the user. Training is an expense that is budgeted for, and if the brass thinks that they won't be able to do business with the policies that are implemented.... heh. They WILL allocate an adequate amount of funds for training/re-training in the budget to accommodate ;) In part, it's this scenario where many of us have catered and caved into the user's mindset of being too lazy to do something correctly that requires us to teach them twice. I guarantee they'll be able to learn to u/l files to a password protected FTP server (or use a web-drive like in OpenWebMail), as well as educate their colleagues and associates as to how they might do the same thing on the other end - if in fact that is the decision the MIS department "Deems" neccessary to face the threat of email exploits. In some of the worlds largest enterprises that I've worked for, I've seen a lot of different policies, the same policy not being neccessarily correct in two different places either. But my first inclination wouldn't be to block any sort of attachments (the exception would be size quotas, which most users will silently view as something to work around since they are still of the mindset that huge emails are abuse on a network). Sure, you could block .zip files and tar.gz's and the users would merely stop compressing the files/bundles - and you would have acheived your short term goal. What I would be inlcined to suggest, and I've been part of groups that have done this in the past, is make the users and their respective departments directly responsible for damages to IT equipment as a result of 'operator error', following a mandatory training session addressing the email package delivery exploits. It's a tough sell, but not to your MIS director, and maybe not to the central authority for decision making. I sold it to a couple of CEOs (Mattel and Disney Studios) and even one of the CFO's fought it tooth and nail, but it put money back into the MIS budget that would have been otherwise lost. Once you educate a user with a seminar via the HR department, and have them sign a statement saying they've completed the training and understand it, very few users will be inclined to do something that get's them written up after the first couple of incidents. If they have any questions for the help desk they can just be told to categorically delete the mail and ask the sender to resend it again, or verify the attachment with the sender. Well, I started off with a short comment and it turned into a draft for yet another presentation. I hope it is received as useful to *some* on the list :) -- Kindest regards, Bradley D. Thornton Manager Network Operations NorthTech Computer Tel: +1.949.218.0682 FAX: +1.949.218.0683 mailto:Bradley () NorthTech US ----------------------------------------------- There are 10 kinds of people in this world... Those who understand binary and those who don't ----------------------------------------------- ********** Participation and subscription information for this EDUCAUSE Discussion Group discussion list can be found at http://www.educause.edu/cg/.
********** Participation and subscription information for this EDUCAUSE Discussion Group discussion list can be found at http://www.educause.edu/cg/.
Current thread:
- Bagle.j out Theresa Semmens (Mar 02)
- <Possible follow-ups>
- Re: Bagle.j out Marty Hoag (Mar 02)
- Re: Bagle.j out Jason Richardson (Mar 02)
- Re: Bagle.j out James Morris (Mar 02)
- Re: Bagle.j out Gary Flynn (Mar 02)
- Re: Bagle.j out Tim Lane (Mar 02)
- Re: Bagle.j out Bradley D. Thornton (Mar 03)
- Re: Bagle.j out Jack Suess (Mar 03)
- Re: Bagle.j out Michael_Maloney (Mar 03)
- Re: Bagle.j out Iljun Kim (Mar 03)
- Re: Bagle.j out Joe St Sauver (Mar 03)
- Re: Bagle.j out Cal Frye (Mar 03)
- Re: Bagle.j out Gordon D. Wishon (Mar 03)
- Re: Bagle.j out Marty Hoag (Mar 03)
- Re: Bagle.j out Matthew Dalton (Mar 03)
- Re: Bagle.j out Scott Weeks (Mar 03)
- Re: Bagle.j out Kevin Shalla (Mar 03)