I’m beginning my summer class in the Infosec program at James Madison University. The class is on Policy Ethics and the Law in Cyberspace. I’m sure over the upcoming weeks my opinions will change on this. But since I saw a related article over at CSO Online, I figured I’d post this article this week. I can always post updates later on.
One of our assigned readings for this week is on the TJ Hooper trial of 1931. Basically two tug boats were hauling barges of coal from Hampton Roads, Virginia to New York. During the trip a storm came up and the last barge in each barge train sunk. The otherside said that 90% of tugboats were equipped with radios to receive the weather forecast and if these operators had gotten the forecast then they would have taken refuge. The trial judge held that although a weather radio was not required by law or by maritime code that it was a best practice for the industry. Since the operator failed to follow best practices the tugboat was culpable.
You might ask why we are studying maritime law in a cyberlaw class. I suspect part of it has to do with the professors predilection for sailing. 
If we can be found at fault for incidents caused by our failure to follow industry best practices, we need to be able to prove the steps that we have taken to protect our systems.
In the context of reading this Hooper case, I found an article over at CSO Online called A Foreseeable Future. The article states that in cases related to 9/11 courts have held terrorism to be a foreseeable threat. I would imagine that the level of applicability of that decision is related to your companies exposure to terroristic concerns. An airline clearly knows it is exposed to terroristic threats. Why else do we have screenings. The World Trade Center was clearly on notice after the first attack with the truck bomb. Where I work, probably doesn’t have the same mandate.
However, this is still an important decision for us I.T. folk. CSOOnline states “typically a criminal act severs the liability of the defendant, but that doctrine has no application when the [action] is foreseeable.”
The article shows this in a case involving Verizon and the Maine Public Utilities Commission. Verizon felt that it was ok to violate their SLA because they were victimized by SLAMMER. It was ruled that
1. Security patches are foreseeable, they occur every month.
2. A reasonable man patches their systems (the competitors in ATT and Worldcom did patch successfully)
3. Verizon is accountable for the damage caused by their failure to patch.
I always wonder just who it is who establishes these best practices. To protect ourselves from judgment, we need to be able to prove in court that we follow best practice. The second recommendation of the article is that we pursue cyberinsurance (which will likely involve first proving that your company follows best practices).
Archive for May 2004
Requiring Foresight
Network World VoIP Security Challenge
Network World has put two leading Voice over IP solutions to the test in what they claim is the world’s first public VoIP security challenge. In this challenge they invited multiple vendors to come in and set up a complete and secure network. Network World then had a red team try to disrupt services.
The full article is here.
What they concluded is that it is possible to secure a VoIP network, but it is not cheap. Also it requires planning and expert help which is basically what I was trying to point out in my earlier post.
VoIP Security Concerns
Voice over IP is an alluring goal for I.T. departments. They promise the ability to rid the department of expensive duplicate networks for data, ease the administrative burden for when users change, and lets not forget provide flashy new features like a color touch lcd display.
In that eagerness to grab the promised cost savings of VoIP it is important not to run past security considerations. NIST recently released a recommendations guide for VOIP.
Their starting guidelines are:
1. Separate voice and data on logically different networks. Different subnets with separate RFC 1918 address blocks should be used for voice and data traffic, with separate DHCP servers for each.
2. At the voice gateway, which interfaces with the PSTN, disallow H.323, SIP, or MGCP or Megaco/H.248 connections from the data network. Use strong authentication and access control on the voice gateway system, as with any other critical network management component. Strong authentication of clients towards a gateway is often very difficult. Here, access control mechanisms and policy enforcement may help.
3. Use firewalls designed for VOIP traffic, through either ALGs or Firewall Control Proxies. Stateful packet filters can track the state of connections, denying packets that not part of a properly originated call. (This may not be possible/feasible, when multimedia protocol inherent security or lower layer security is applied, e.g., H.235 Annex D for integrity provision or TLS to protect SIP signaling.)
4. Use IPsec or Secure Shell (SSH) for all remote management and auditing access. If practical, avoid using remote management at all and do IP PBX access from a physically secure system.
5. If performance is a problem, use encryption at the router or other gateway, not the individual endpoints, to provide for IPsec tunneling.
The full article is definitely worth a read. Those are general recommendations having to do with VoIP. There are also problems with SIP the communications protocol used by VOIP phones as well as problems with specific implementations.
After reading that article, I did some googling and found some interesting articles.
The first link is from Sys-Security. They are a cool group that I respect.
http://www.sys-security.com/archive/papers/The_Trivial_Cisco_IP_Phones_Compromise.pdf
They talk about configuration vulnerabilities due to the use of TFTP amongst other things.
Cisco’s rebuttal is at http://www.cisco.com/en/US/products/hw/phones/ps379/products_tech_note09186a00800e251b.shtml
The second link is from British tech website, the register.
http://www.theregister.co.uk/2004/02/20/cisco_voip_kit_open/
Cisco hadn’t responded in time for the register article above. They respond in http://www.theregister.co.uk/2004/03/05/cisco_dismisses_voip_snooping_concerns/ where some security steps are detailed.
http://www.cisco.com/en/US/products/products_security_advisory09186a0080094ac6.shtml
http://www.securiteam.com/exploits/5HP0O0U75Q.html
I think that it is possible to deploy VoIP on an internal network in a secure fashion. However, security concerns must be addressed. Vendors should assist companies in implementing a secure solution. After all we are all plenty busy trying to keep our computers secure. We dont need to add phone patch management to the problem list.
Enterprise Spyware Protection
Spyware is a problem effecting enterprises more and more. I think we are at a point similar to where we were with spam a year ago. It is starting to build to the point where users will not accept it any more. It is slowing the systems and exposing companies to legal liability. I predict that by this point next year anti-Spyware software will be expected by the users just as anti-spam solutions are expected now.
Currently, there is an ad hoc approach. The smart users don’t get Spyware installed or they are able to install adaware or spybot and take care of the problem for themselves. Other users are left calling the helpdesk and you’ve now got downtime for the user as the anti-Spyware software is installed, updated and run. Most of the products aren’t even able to remove all threats.
If you push out the antispyware software on all users, and provide instructions on updating and running the software monthly or as they have problems, that is a solution destined for failure. It reminds me of antivirus software pre 1999ish.
A corporate network demands a centralized antispyware solution. Not because your companies computer guy wants to stay in control (well that too). Rather it is important to make sure that the software is consistently run and updated. If there is a problem it should report back to a centralized point so that the helpdesk can be dispatched.
Over at myitforum.com we’ve been talking about various ways of preventing Spyware.
1. User Education. Users should be aware that “free” applications often come at a price. Also when they are surfing they need to be careful about what they say yes or ok to. Often its better to just close the windows on a popup
2. Browser configuration – While user education might help with the adware that gums up machines, much Spyware is installed surreptitiously (I need to install IEspell on the computer I’m at) on computers via poor configuration of the IE security levels.
3. Vulnerability Patching – Even fully patched, Internet Explorer is a sieve for letting malicious websites mess with you. (wait, was that a mixed metaphor?) Its best to make sure everything on your system is well patched.
4. Personal firewalls that manage outbound activity can be helpful in letting you know what programs on your system are doing. They are also one humongous pain in the rear.
5. Install antispyware applications.
After reviewing non-software protections, I decided it was time to look at anti-Spyware software. The antivirus companies are getting into the antispyware game. Symantec has it in 2004, and possibly 2003 consumer versions. SAV 9 corporate edition has Spyware protection also. McAfee is known to have Spyware definitions as well.
The question is how well do they fare?
I cant speak to McAfee since I’m a Symantec customer, but my cohorts at myitforum tell me that it isn’t that great. Its difficult to separate the virus reports from the Spyware reports. And often detection is ok, but removal is nonexistent.
That matches my experience thus far with Symantec. I was surprised to find that I could only scan for Spyware during manual scans and scheduled scans. That was rather disappointing. The good news is that scanning for Spyware isn’t all or nothing. I can choose to scan for Spyware and adware, but not jokes and hacking tools. This is important because it may be completely normal in your company to be running l0phtcrack or even more innocent things like samspade or netcat which some Spyware vendors detect as hacking tools.
Important Features for Corporate Antispyware
1. Mechanism to control updates
2. Real-time scanning capabilities, not just scheduled scan
3. Centralized reporting
Thus far the anti-Spyware software reviews I have seen are all about software designed for the end user. I’m currently looking at Symantec Antivirus 9, Pest Patrol Corporate Edition, and if they get back to me there is a beta of a enterprise version of Webroot Software’s Spysweeper. I plan to continue this in a part two as I look more closely at specific solutions.
Comcast plan to stop Spam
Comcast’s users have been one of the largest sources of U.S. originated spam. Other large ISPs (Cox and AOL) have taken to blocking end user access to any mail server other than their own on port 25. While this was annoying at first, there were many workarounds available for most users. As a Cox customer it annoyed me to no end that Comcast customers were protected from Cox spam, but we weren’t protected from Comcast spam.
Now, Cox has finally decided to take some action. They feel that blocking outbound 25 to all users would result in too many calls to their call centers, so they are going to be blocking 25 to computers that send out an unusual amount of email. Since a user is breaking the terms of service, I think this is an acceptable action. It doesn’t paint all uses with a broad brush the way the Cox action did.
I tend to say lets wait and see. It seems to me that this policy by definition will allow spam out before the computer is blocked. This is still a great improvement over what they were doing.
Did They Read It?
There seems to be a lot of controversy lately surrounding didtheyreadit.com. This company adds a webbug to your outgoing messages so that when the message is opened the web browser will open the webbug and signal the message as read. This is much more powerful than the standard return receipt because the return receipt requires the mail server or the mail client software to cooperate and return the receipt. Often by default the user is told of the return receipt request and they can say yes or no. Didtheyreadit.com attempts to signal back without the user being aware.
The can fail to work for a number of reasons.
1. Perhaps you have a personal firewall that blocks HTTP connections from the email client.
2. Perhaps you are running a text based mail client that will not load images.
3. Perhaps you are running Outlook 2003 which does not load images from non-trusted users by default.
Also who really wants to run all their mail through a untrusted server just to have them add the webbug in? If its important enough to get a return receipt, why trust it to a unknown third party.
But I didn’t really write this article to discuss the features and drawbacks of didtheyreadit.com. That really isn’t important to me.
I am amazed by the flurry of articles surrounding this product. The privacy nuts are out in full force. Imagine, a sender knowing when their email was read. What an outrage. Also the Linux zealots are also printing articles about how their text mail reader of choice doesn’t rat out when your email was read. I
This is nothing new, and its getting way to much press. If this continues a couple more days, I suspect congress will pass a law against it. Probably in CAN-SPAM part 2. That is if they haven’t already recessed for the summer.
http://www.usatoday.com/tech/news/techinnovations/2004-05-20-email_x.htm
http://arstechnica.com/news/posts/1085359926.html
http://slashdot.org/article.pl?sid=04/05/23/2146200
W32.Korgo.a
W32.Korgo.A is a worm that attempts to exploit Microsoft LSASS Windows vulnerability, described in Microsoft Security Bulletin MS04-011.
At a certain point all of these worms going after one vulnerability gets kind of old. Its kind of like shooting ducks in a barrel isn’t it? Anyone still not patched kind of deserves what they get if they ignored the first worm.
http://www.symantec.com/avcenter/venc/data/w32.korgo.a.html
Microsoft Antivirus Defense in Depth Guide
Microsoft has provided an antivirus defense in depth guide. http://www.microsoft.com/downloads/details.aspx?FamilyID=f24a8ce3-63a4-45a1-97b6-3fef52f63abb&DisplayLang=en
I don’t quite understand why they choose to make documents available via MSI. Do I really need to get yet another item in my start menu just to read a pdf? The first thing I note after installing the document is that the pdf is 666 KB. Apparently this antivirus document is of the devil.
This is a long document that begins with a brief definition and history of viruses, and moves on to many best practices that should be implemented. It is well worth a read.
Spammer Testifies that CAN-SPAM is license to spam
Ronald Scelson is upset. He says he complies with CAN-SPAM yet ISPs wont let him spam at will. Oh the humanity! You mean to say that CAN-SPAM wasn’t meant to be the spammers enablement act? Both pro and anti spammers have said that this is the likely outcome of the federal legislation. As long as the spammer has legit headers and contact information he is in the clear.
Was this legislation really meant to dictate whether an ISP can enforce their Acceptable Use Policy? Richard Scelson seems to think so. I suppose someday some wrongheaded judge will agree with him.
Cisco’s Self Defending Network
I went over to Cisco in Herndon this morning to see a presentation on Cisco’s self-defending network. The goal of this product seems to differ from what I had been thinking of. My goal had been endpoint compliancy, and their product doesn’t do that today at all. It may do it tomorrow or in a few months. I translate that into the 12th of never, or whenever we feel like it. I know they have the Cisco Trust Agent coming out in July-August timeframe, so at least they are working on it.
Infoexpress has a product called Cybergatekeeper Lan and Cybergatekeeper remote. It allows the administrator to require that everyone on the network have passed an audit. It can check for the presense of antivirus software (by looking at processes, file versions and config files), that the AV software is up-to-date and configured correctly. If they dont have a template for the AV software you use, you can create one for yourself. The same is true for requiring patches or any other software. You can also prohibit machines with specific executables. You might do this to keep a specific virus off the network.
The problem with the Infoexpess approach at present is that it is extremely manual. When Sasser came out on a Saturday, I needed to write a rule to look for systems with that EXE.
Cisco does not currently match up at all with the Infoexpress product. They are working on a product called the Cisco Trust Agent. They are partnering with the four leading antivirus companies to create a agent built into the AV product that will report to the cisco management device the status of the antivirus so the machine can be isolated if it is not up to snuff. Very little is available on this product as it is not released yet. However, I have been told that it does not do enforcement of other things like personal firewalls or patches. In fact we do not yet know what level of enforcement will be possible for the antivirus product. I like to require that all files be scanned for example.
Where Cisco gets interesting is in the IDS product. Generally IDSes have been something that you hang outside your firewall or just before your DMZ. This IDS goes on the core routers of the company. This way it can do enforcement on all internal traffic. So you may get infected because I cant force you to patch, but I can shut you down once you do get infected. Perhaps a reasonable accommodation to people who dont want me to have any control over their system.
Another part of this IDS is the Cisco Security Agent. This is a host based intersion prevention system. It is behavior based in that it looks for activity it wouldn’t expect for the role that you have assigned to the computer. If I say that a server is running IIS, the agent recognizes the correct behavior of IIS and will take action if IIS starts spinning out of control or contacting a bunch of other servers on port 80.
Another interesting security feature is 802.1x. If a user is authenticated, they are placed on the corporate lan. If they are not, then they drop into a restricted vlan that may have access to the Internet only (still restricted by websense and behind the corporate firewall).
A lot of products in a short period of time, but it is exciting to see what can be done to keep the network safe. Speaking of safe, time to see if we can crack open the safe to get some money to pay for this.
