Keeping your (digital) archive
Steve posted a link to a story about NASA's effort to read a bunch of tapes from the 60s:
http://www.latimes.com/news/nationworld/nation/la-na-lunar22-2009mar22,0,1783495,full.story
The story is about the effort and cost needed to read tapes from unmanned space missions that a.o. mapped the surface of the moon. The big issue is the difficulty of finding -restoring- a tape drive for the tapes they used back then.
Are we today doing better with our (digital) archive than NASA did 40 years ago?
- CDs/DVDs: sure the drives are common, but will they remain so? How about CD-rot ? How long will the disks actually remain readable, esp. those writable ones ?
- Blueray: will it become a big success or not and still be around in X years ?
- Tapes: a breed on a path to extinction already!? How about backward compatibility? How long do tapes actually remain readable ?
- Harddisks are cheap! Same here: how long can they be kept in working order? What if the interface changes (a drive of a decade old PC, will it actually work in a modern PC? How about one 20 years old?)
- File formats: EBCDIC and ASCII will go a long while, but if you need to express more than English they become rather limited. What about "office": what if Microsoft doesn't make or exist anymore in X years ? What if PDF isn't the preferred interchange format anymore at some point in time?
After all who can edit a 20 year old wordperfect document today? - Online services (e.g. storing it in a gmail mailbox) are possibly even more tricky (what if Google ...)
- Niel pointed out some more problems:
- (propietary) floppies and floppy drives, computers using casettes to store data, zip drives.
- Archive software sometimes isn't all that common (he pointed to old Apple archives)
- ...
If you take small steps it all can grow with you, you buy a new technology to store it, and you still have the old media or format readable.
But big steps are far more trouble than small ones.
So how can you make it works for your archives:
- At the computer science department where I worked many years ago, every year we read 1/3 of the archive (was on tape) and converted it to new media (Being a unix shop, there was little need to convert formats, but it was taken into account for e.g. framemaker documents), so the media in the archive were kept in two copies, both at most 3 years old.
I saw the reduction of stacks of 1/2 inch tape into a few exabyte tapes. And on the next run the exabyte tapes were of a higher density ...
3 years might seem short: media do last longer, but there is a safety factor to consider. 3 years was also short enough to allow for the hardware usd to create it, to still have a support contract active on it by the last time we needed to read it. - Use multiple formats for every item: don't just bet on .doc (or .docx), open office, .pdf or even a collection of tiff files, bet on all at the same time. Keep them all. Even that image could be -worst case- input into OCR to get to a new format if it really has to be done.
Make sure to also archive a computer system that can edit the data. This is sometimes critical, especially with proprietary data formats.
Make sure to update the formats to the latest versions in addition to the original so that you have a better chance for backward compatibility with future products. - Archive complete machines when needed. Now archiving hardware is tricky, it's the part that breaks with old age ... But you can virtualize the machine. If you keep .e.g old accounting systems for which you long since lost support from the vendor in a VMware image that you never run, but only clone and let it be consulted as/when needed. (and wipe the clone after every use), you can continue to run it for a long while even if the hardware is long obsolete, the OS is long since unsupported and not safe to run on your normal network anymore, etc. While still keeping access to the proprietary data possible.
- Have a policy in place to not let hardware support expire before all the archive is updated away from the technology.
- Roseman wrote in to remind us to keep the archive in multiple locations, not just one.
- Niel wrote in to tell some successes on having done conversions for his friends:
- Keep old networks around (10base2, old hubs, and their cabling).
- Keep old computers around like a mac with system 8 on it.
- Keep serial ports (while the technology still exists) to allow to transfer data from one machine to the next.
- ...
Other success stories ? Send them in via the contact page!
Before you ask what this has to do with security: It's all about availability!
--
Swa Frantzen -- Section 66
April Black Tuesday Overview
Overview of the April 2009 Microsoft patches and their status.
| # | Affected | Contra Indications | Known Exploits | Microsoft rating | ISC rating(*) | |
|---|---|---|---|---|---|---|
| clients | servers | |||||
| MS09-009 | Multiple memory corruption vulnerabilities allow random code execution. Also affect Excel viewer and Mac OS X versions of Microsoft Office. Replaces MS08-074. |
|||||
| Excel CVE-2009-0100 CVE-2009-0238 |
KB 968557 |
Actively exploited |
Severity:Critical Exploitability:2,1 |
PATCH NOW | Important | |
| MS09-010 | Multiple vulnerabilities allow random code execution Replaces MS04-027. |
|||||
| Wordpad & office converters CVE-2008-4841 CVE-2009-0087 CVE-2009-0088 CVE-2009-0235 |
KB 960477 | Actively exploited. CVE-2008-4841 was SA960906 |
Severity:Critical Exploitability:1,2,1,1 |
PATCH NOW | Important | |
| MS09-011 | MJPEG (don't confuse with mpeg) input validation error allows random code execution Replaces MS08-033. |
|||||
| DirectX CVE-2009-0084 |
KB 961373 | No publicly known exploits | Severity:Critical Exploitability:2 |
Critical | Important | |
| MS09-012 | Multiple vulnerabilities allow privilege escalation and random code execution. Affects servers with IIS and SQLserver installed and more. Replaces MS07-022, MS08-002 and MS08-064. |
|||||
| Windows CVE-2008-1436 CVE-2009-0078 CVE-2009-0079 CVE-2009-0080 |
KB 959454 | Actively exploited, exploit code publicly available. | Severity:Important Exploitability:1,1,1,1 |
Important | Critical (**) |
|
| MS09-013 | Multiple vulnerabilities allow random code execution, spoofing of https certificates and NTLM credential reflection. Related to MS09-014 (below). |
|||||
| HTTP services CVE-2009-0086 CVE-2009-0089 CVE-2009-0550 |
KB 960803 | Exploit is publicly known. | Severity:Critical Exploitability:1,1,1 |
Critical | Important | |
| MS09-014 | Cumulative MSIE patch. Replaces MS08-073, MS08-078 and MS09-002. Related to MS09-10, MS09-013 (above) and MS09-15 (below). |
|||||
| IE CVE-2008-2540 CVE-2009-0550 CVE-2009-0551 CVE-2009-0552 CVE-2009-0553 CVE-2009-0554 |
KB 963027 | Exploit code publicly available | Severity:Critical Exploitability:3,1,2,3,3,1 |
PATCH NOW | Important | |
| MS09-015 | Update to make the system search for libraries first in the system directory by default and an API to change the order. Replaces MS07-035. Related to MS09-014 (above). |
|||||
| SearchPath CVE-2008-2540 |
KB 959426 | Attack method publicly known SA953818
|
Severity:Moderate Exploitability:2 |
Imporant | Important | |
| MS09-016 | Multiple input validation vulnerabilities allow a DoS and XSS. | |||||
| ISA server CVE-2009-0077 CVE-2009-0237 |
KB 961759 |
CVE-2009-0077 is publicly known. |
Severity:Important Exploitability:3,3 |
N/A | Critical | |
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
- We use 4 levels:
- PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
- Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
- Important: Things where more testing and other measures can help.
- Less Urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.
- The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
- The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-case role.
- Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
- All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them
(**): For shared IIS installations: upgrade this rating to PATCH NOW
--
Swa Frantzen -- Section 66
Oracle quarterly patches
Oracle also released their quarterly load of patches today.
In total 43 vulnerabilities were fixed.
See http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpuapr2009.html
It contains CVSS ratings (risk matrices in Oracle lingo) and the parameters used for all vulnerabilities fixed.
One needs a metalink account to get to further details.
--
Swa Frantzen -- Section 66
VMware exploits - just how bad is it ?
When Tony reported on the release of new VMware patches on April 4th, we didn't immediately spot that the same day there was also a release of a for-pay exploit against CVE-2009-1244 (announced in VMSA-2009-0006).
Seems a few days later, there is also a white paper available -for pay as well-, and now also a flash video of the alleged exploit showing a XP client OS exploiting a Vista host OS (launching calc.exe). The video also comments that they get a data leak back from the host to the client (hard to tell, all you see is a number of pixels being mangled on the screen).
The consequences of this are important. Virtualisation is often used just to consolidate different functions on a shared hardware, and I've seen great uses of it to e.g. be able to continue to run an accounting package that needed an OS that would not run anymore on modern hardware. I've also seen great uses where they cloned images of machines in order to let users have access to archived machines, and then remove the clone after use in order to preserve integrity of such systems.
But there are more risky uses:
- Virtualisation is also often used instead of physical separation of systems and vulnerabilities like this one and the exploits against it are a real issue one needs to address if virtualisation is goign to be used as a security measure.
I've helped with a number of studies where such use was contemplated for highly critical assets, not just using windows and vmware, but also using nearly mainframe grade unix solutions. I always had the viewpoint that software separation is always going to be more risky than an airgap.
But it's a hard sell as there often is no hard evidence that it can be broken (and vendors usually tell your customer it cannot). That flash video might be what one needs to stop those taking chances they ought not to take and consider the benefits vs. the risk they are taking. - Those doing malware investigation often use virtual machines to do so as its easier to wipe them after they get infected and it's possible to run a number of them to let them communicate etc. They already face a situation where the attackers detect vmware in the malware and refuse to let it run it's course (and be studied without actually understanding the machine code). If you don't keep up to date (and even if you do - the exploit was available for sale on the same day as the patch, hence it existed earlier- that separation might still lead to exploitation of the host OS.
--
Swa Frantzen -- Section 66
Comments