by By now, I’m sure everyone with a Sun system has heard about the widely disseminated vulnerability in Solaris 10’s telnetd code. My experiences in managing that issue from early announcement to patch might serve as a warning/aide to others who are looking at security models.
Several lessons were learned as a result of the experience. Some were things that worked well, some were things that I feel would hopefully be improved.
* In the event of a zero day disclosure, the vendor is likely to be among the last to admit to the issue. Sun did not issue an alert until they had something more than “shut down telnetd” Alternative means of learning of security vulnerabilities are a must.
* It’s critical to have a list of contacts pre-built for communicating emergency changes. In this case, numerous support groups outside the sysadmin community had to be notified that telnet could not be counted on working anymore.
* A clear decision path should exist on determining what the remediation steps are to be, as well as a way for that information to be communicated out to all system administrators.
* There needs to be a way for individuals who may have alternative solutions to communicate that back up the communication path for consideration.
* Some process needs to exist to reliably determine/document what servers are potentially vulnerable, and which ones have been remediated. Don’t take “I fixed all my servers” from anyone. Especially in these situations, people may have a different idea of remediation and may not have actually fixed the issue.
* Testing resources are important. Some place where prospective solutions can be tested.
* Make sure you have trusted communication lines open (not open email) where details can be sent if needed.
* Vendor on site contacts should also know who they are to work with for security emergencies, it may not be the normal contact.