Slashdot Mirror

You're right; sorry. Try this one: http://www.itl.nist.gov/iad/894.05/docs/CDandDVDCareandHandlingGuide.pdf, looking at pages 21-22. Also see the notes about adhesive labels on page 23. They're also a no-no. Pat

Don't hold your breath. Although the Federal Desktop Core Config (FDCC) only mandates *security settings* for federal gov't XP/Vista machines, many IT PHBs have taken it as a mandate to USE Windows for the desktop environment. Hard to blame them, if you just go by the title of the program. I mean, where's the Linux FDCC, or the Mac version? Oh, that's right... they don't exist (yet).

Add to that the fact that AD, Exchange, SharePoint, OCS (among others) are de-facto standards across the DoD, and you can see where that leaves us for desktop machines. Not impossible to integrate alternative OS's, just very difficult; and nearly impossible to reap all those "MS-unique features" from your Windows servers w/out Windows/IE/Outlook/OCS on the other end.

I think it's safe to say that vendor lock-in has been achieved.

(Ordinary DVDs last anywhere from 3 to 12 years, on average.)

For those of you really concerned about optical media in your possession, check out NIST's "Care and Handling of CDs and DVDs - A Guide for Librarians and Archivists" [1.24 MB PDF warning]. That guide is extremely thorough.

While it is a longer span for pressed DVDs, I'm sure the RIAA/MPAA know that the media we purchase songs and movies on has a limited lifespan that may very well be shorter than the consumer's remaining years. And it kind of upsets me that creating backups for your own personal use of DVDs or CDs is illegal (although not typically prosecuted unless copyright infringement ensues). Personally, I rip all my CDs and some DVDs upon purchase and simply never use the disc again. It goes into storage and I create digital backups and hard copy backups of the discs. It's a bit pricier and not as instant as other ways of purchasing media but it ensures I'll always have it. When I purchased the latest Cloud Cult album, I bought the CDs and was able to download unencrypted MP3s immediately after purchase. When I purchased the vinyl record of She & Him, I was e-mailed a voucher to download the MP3s. I wish the big distributors would follow what the little guys are doing and offer you the whole package up front. Saves me a lot of work.

The Imperial System of measurements is not the same as the customary measurements used in the United States. The legal arbiter of measurements in the United States is the National Institute of Standards and Technology. Apendixes B [PDF] and C [PDF] to their Handbook 44 provide a good overview of the structure of the respective standards and their relationship to SI (the science based International System, which was based on the Metric System).

The word system seems misleading when applied to US customary measures. For example:

Appendix B. Section 2.2.5. From 1893 until 1959, the yard was defined as equal exactly to 3600/3937 meter. In 1959, a small change was made in the definition of the yard to resolve discrepancies both in this country and abroad. Since 1959, we define the yard as equal exactly to 0.9144 meter; the new yard is shorter than the old yard by exactly two parts in a million. At the same time, it was decided that any data expressed in feet derived from geodetic surveys within the United States would continue to bear the relationship as defined in 1893 (one foot equals 1200/3937 meter). We call this foot the U. S. Survey Foot, while the foot defined in 1959 is called the International Foot. Measurements expressed in U. S. statute miles, survey feet, rods, chains, links, or the squares thereof, and acres should be converted to the corresponding metric values by using pre-1959 conversion factors if more than five significant figure accuracy is required.

Does this make a difference? From one viewpoint, no, when do you ever need to keep something accurate within 2 mm over a mile? From another, yes, repeated iterations of computations based on incorrect conversions can produce just plain gibberish. Another bit of measurement chaos to keep in mind:

Appendix B. Section 2.3. British and United States Systems of Measurement. ... In the customary British system, the units of dry measure are the same as those of liquid measure. In the United States these two are not the same; the gallon and its subdivisions are used in the measurement of liquids and the bushel, with its subdivisions, is used in the measurement of certain dry commodities. The U. S. gallon is divided into four liquid quarts and the U. S. bushel into 32 dry quarts. All the units of capacity or volume mentioned thus far are larger in the customary British system than in the U. S. system. But the British fluid ounce is smaller than the U. S. fluid ounce, because the British quart is divided into 40 fluid ounces whereas the U. S. quart is divided into 32 fluid ounces. ...
1 U. S. fluid ounce = 1.041 British fluid ounces
1 British fluid ounce = 0.961 U. S. fluid ounce
1 U. S. gallon = 0.833 British Imperial gallon
1 British Imperial gallon = 1.201 U. S. gallons

We also must remember that NASA has proven itself incapable of managing the different systems of measurement before. Ten years ago NASA crashed a Mars bound probe because of botched conversions from customary to SI units. You would think that having paid $125 million for that lesson, they would want to avoid a recurrence. But, I suppose that they are from the government and they do not have to care.

The Imperial System of measurements is not the same as the customary measurements used in the United States. The legal arbiter of measurements in the United States is the National Institute of Standards and Technology. Apendixes B [PDF] and C [PDF] to their Handbook 44 provide a good overview of the structure of the respective standards and their relationship to SI (the science based International System, which was based on the Metric System).

The word system seems misleading when applied to US customary measures. For example:

Appendix B. Section 2.2.5. From 1893 until 1959, the yard was defined as equal exactly to 3600/3937 meter. In 1959, a small change was made in the definition of the yard to resolve discrepancies both in this country and abroad. Since 1959, we define the yard as equal exactly to 0.9144 meter; the new yard is shorter than the old yard by exactly two parts in a million. At the same time, it was decided that any data expressed in feet derived from geodetic surveys within the United States would continue to bear the relationship as defined in 1893 (one foot equals 1200/3937 meter). We call this foot the U. S. Survey Foot, while the foot defined in 1959 is called the International Foot. Measurements expressed in U. S. statute miles, survey feet, rods, chains, links, or the squares thereof, and acres should be converted to the corresponding metric values by using pre-1959 conversion factors if more than five significant figure accuracy is required.

Does this make a difference? From one viewpoint, no, when do you ever need to keep something accurate within 2 mm over a mile? From another, yes, repeated iterations of computations based on incorrect conversions can produce just plain gibberish. Another bit of measurement chaos to keep in mind:

Appendix B. Section 2.3. British and United States Systems of Measurement. ... In the customary British system, the units of dry measure are the same as those of liquid measure. In the United States these two are not the same; the gallon and its subdivisions are used in the measurement of liquids and the bushel, with its subdivisions, is used in the measurement of certain dry commodities. The U. S. gallon is divided into four liquid quarts and the U. S. bushel into 32 dry quarts. All the units of capacity or volume mentioned thus far are larger in the customary British system than in the U. S. system. But the British fluid ounce is smaller than the U. S. fluid ounce, because the British quart is divided into 40 fluid ounces whereas the U. S. quart is divided into 32 fluid ounces. ...
1 U. S. fluid ounce = 1.041 British fluid ounces
1 British fluid ounce = 0.961 U. S. fluid ounce
1 U. S. gallon = 0.833 British Imperial gallon
1 British Imperial gallon = 1.201 U. S. gallons

We also must remember that NASA has proven itself incapable of managing the different systems of measurement before. Ten years ago NASA crashed a Mars bound probe because of botched conversions from customary to SI units. You would think that having paid $125 million for that lesson, they would want to avoid a recurrence. But, I suppose that they are from the government and they do not have to care.

I don't know....NIST, anyone? Oh, wait. How about the incredible lust for patents as a reason we don't invest more in government research?

There. One reason why we should invest. And one reason why it doesn't happen as often as it should.

http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf

http://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdf

http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf

http://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdf

But there is more:

(3) "Secure and reliable forms of identification" for purposes of this directive means identification that (a) is issued based on sound criteria for verifying an individual employee's identity; (b) is strongly resistant to identity fraud, tampering, counterfeiting, and terrorist exploitation; (c) can be rapidly authenticated electronically; and (d) is issued only by providers whose reliability has been established by an official accreditation process."

OPM had little to do with the requirement. Simply walk the logic tree of the directive. In order to both verify the applicant's identity and resist fraud and exploitation, a background investigation is a virtual necessity. And since contractors would be given effectively the same access as federal employees, it follows that contractors will need to undergo the same background checks as applicants for federal employment have had to undergo since 1953:

http://www.archives.gov/federal-register/codification/executive-order/10450.html

And nothing was done by "Stealth" There was a long and painful review and public comment period during NIST's development of the implementation standard:

http://csrc.nist.gov/groups/SNS/piv/comments.htm

The name of the House Committee escapes me, but they do yearly reports on computer security and gov't agencies regularly get Ds (up from their previous Fs).

The big question is what do these grades really mean? Do they really provide any true indication as to how effective the Government is at securing their systems? Is a 'D' all that much better than a 'F'? And what does it mean if an organization manages a 'B' (mine did)?

But at the same time, I get a feeling that it sort of does give an impression as to where things are. A 'D' just isn't all that great. But it is better than a 'F'.

My little nook of the Fed world improved over the years. Infosec took on new meaning when the top of the Fed hierarchy started throwing around requirements and putting on their serious face. I would imagine things ARE getting better all in all. It's just darned hard to tell how much better.

http://csrc.nist.gov/groups/SMA/fisma/index.html demonstrate its compliance with the security requirements as opposed to how well the requirements are actually implemented.

NIST Special Publication 800-53 is what I had in mind. It's generated a ton of work for contractors to bring in auditors. And in my (limited) experience, it's a great opportunity for someone with no infosec background to "get in to security" as auditors are simply required to follow the documentation. Said documentation can be turned on it's ear by a sufficiently adept beurocrat in some cases (and avoided if your auditor isn't too technical in others). But despite my cynicism... it's something. There ARE some good practices in that document. And NIST has put out some nice automated scripts to help hash it all out (best keep an eye on what its doing though). So it's not ALL bad. Just not great.

And that's why we get agencies that think they've secured their networks when they haven't (the more redtape exists, the more loopholes there are).

The name of the House Committee escapes me, but they do yearly reports on computer security and gov't agencies regularly get Ds (up from their previous Fs).

http://csrc.nist.gov/groups/SMA/fisma/index.html demonstrate its compliance with the security requirements as opposed to how well the requirements are actually implemented.

By default the author's spreadsheet calculates how long it takes to guess a *likely* password based on the NIST model
http://csrc.nist.gov/publications/drafts/800-63-rev1/SP800-63-Rev1_Dec2008.pdf of the amount of entropy in a likely password. If you look at the "Entropy Models" tab of the spreadsheet you'll see more of this information. If you change the spreadsheet to use a "perfect" entropy model it would require 22,926,448,052.7 guesses per second to find an 8 character password utilizing 96 characters within 90 days. Fortunately for hackers, people don't usually cat /dev/random when generating their password. Some letters are used more than others. Passwords are usually not perfectly random.

Nonsense. The tradeoff is small. Generally speaking, the politically-motivated decision makers are the appointees. They can set the direction of an organization, but they do not do the work. There are thousands of government scientists. They do good SCIENCE, which by it's very nature is truth-driven. Now whether you consider the pursuit of truth "politically motivated" or not is a matter of interpretation.

My brother works for the BFRL at NIST. Now, a lot of what they work on does not affect you. It's pure science. Fire in zero-G, for instance. This stuff would not be funded by commercial science, and much of it is too expensive for non-profit research institutions.

But this pure science-- it spins off in ways you couldn't imagine ahead of time. Being able to synchronize clocks around the world. Being able to buy something that weighs "1 kg" and knowing that, when you get it, it's the same "1 kg" that you meant.

The BFRL at NIST also looks at lots of practical things. Things like "How can we find people trapped in fires?" or "Can we develop a method for city planners to make smart staffing decisions for fire departments?" These practical things are often a direct consequence of pure science that was published many years before. And the scientists themselves, who work down the hall from each other, interact in many unexpected and positive ways. All of these things are of great value, but in many cases, they would not be done for lack of direct money-making potential. Government science keeps us safe, and it keeps our country competitive. It is absolutely essential.

Nonsense. The tradeoff is small. Generally speaking, the politically-motivated decision makers are the appointees. They can set the direction of an organization, but they do not do the work. There are thousands of government scientists. They do good SCIENCE, which by it's very nature is truth-driven. Now whether you consider the pursuit of truth "politically motivated" or not is a matter of interpretation.

My brother works for the BFRL at NIST. Now, a lot of what they work on does not affect you. It's pure science. Fire in zero-G, for instance. This stuff would not be funded by commercial science, and much of it is too expensive for non-profit research institutions.

But this pure science-- it spins off in ways you couldn't imagine ahead of time. Being able to synchronize clocks around the world. Being able to buy something that weighs "1 kg" and knowing that, when you get it, it's the same "1 kg" that you meant.

The BFRL at NIST also looks at lots of practical things. Things like "How can we find people trapped in fires?" or "Can we develop a method for city planners to make smart staffing decisions for fire departments?" These practical things are often a direct consequence of pure science that was published many years before. And the scientists themselves, who work down the hall from each other, interact in many unexpected and positive ways. All of these things are of great value, but in many cases, they would not be done for lack of direct money-making potential. Government science keeps us safe, and it keeps our country competitive. It is absolutely essential.

That method works, but for the day or more it took them to do that, using the Secure Erase ATA command on that drive would have been more secure and taken only an hour or two. The Secure Erase command is part of the ATA standard and present on every ATA drive larger than 15GB. The command "dd" cannot access and erase every sector as ATA drives do not allow access to certain sectors, like reallocated sectors. Even though SCSI drives do not have this limitation, I still wouldn't erase one with "dd", there are probably better open source tools. An even better and faster option for even more secure erasure on ATA drives, is to use the drive in encrypted mode. When done with the drive, toss the encryption key. This makes any data on the drive practically unusable. Reuse of the drive is still possible with a standard reformat after unlocking the drive.

More reading:
Hard Drive data erasure methods are described on page 27 of the PDF or page 19 as printed on the document:
http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf

Describes different methods of data sanitization on magnetic hard drives. Discusses hard drives exclusively, unlike the NIST paper above.
http://cmrr.ucsd.edu/people/Hughes/DataSanitizationTutorial.pdf

Page from the author of the above paper with a DOS program that can send a Secure Erase ATA command to a drive, no source though:
http://cmrr.ucsd.edu/people/Hughes/SecureErase.shtml

However, t13.org the website of the ATA standards body is here, and has the last drafts of standards available here (nearly as good as the actual standards, which cost money):
http://www.t13.org/Documents/MinutesDefault.aspx?DocumentType=4&DocumentStage=2

Start here though for the Secure Erase Command:
http://www.t13.org/Documents/UploadedDocuments/docs2009/d2015r1a-ATAATAPI_Command_Set_-_2_ACS-2.pdf

Just wanted to chime in that the Pauling book above has been used for many years after it's introduction and is extremely well respected. See Pauling's Wikipedia entry for the gist.

Also no one has mentioned Abramowitz and Stegun so far. Relatively recently produced, but is a public domain government work and can be obtained cheaply. Still very useful. It's successor the DLMF has managed to be copyrighted even though it is a government work, and isn't finished yet. Only 5 chapters so far.

Taxman (already moderated)

4500 megabytes is 4.5 gigabytes

4500 mebibytes is 4.39 gibibytes

As so indicated by the proper authority on this subject, the National Institute for Standards and Technology

Just imagine the anti-floridation crowd going ballistic if anyone suggested adding Lithium to municipal water supplies.

Ohhhh.... a chance to tick the anti-fluoridation people twice: Lithium Fluoride
[grin]

It has nothing to do with hisecws.inf. That security template was finally removed in Vista because it caused too much customer pain. Microsoft's guidance is available here: http://technet.microsoft.com/en-us/library/cc677002.aspx. The FDCC is here: http://fdcc.nist.gov/

Out of curiosity, are the settings that the Air Force requested the same as the FDCC settings that are at NIST?

What operating systems have FDCC settings? Currently, FDCC settings are intended for Microsoft Windows XP Professional with Service Pack (SP) 2 or SP 3 and Microsoft Windows Vista Business, Microsoft Windows Vista Enterprise, and Microsoft Windows Vista Ultimate with SP 1.

'The Air Force, on the verge of renegotiating its desktop-software contract with Microsoft, met with Ballmer and asked the company to deliver a secure configuration of Windows XP out of the box. That way, Air Force administrators wouldnâ(TM)t have to spend time re-configuring, and the department would have uniform software across the board, making it easier to control and maintain patches.'

So if you'd like to do it yourself, you can secure your XP too.

http://nvd.nist.gov/fdcc/fdcc_faq.cfm

I'm not sure super secure is the right word for this version of XP though, given that there are a lot of security features it is missing that Vista, Windows 7 and some other OSes have.

Parsing of the questions is the really difficult part of QA. However, the usage of category names isn't something brand new in the field. See the NIST TREC Question Answering competition. The last couple of years' challenges involved a group of questions referencing a "target" and/or the previous question or previous answer to correctly formulate the current answer.

Example:
TARGET: John William King convicted of murder
Q1: How many non-white members of the jury were there?
Q3: Where was the trial held?
Q4: When was King convicted?
Q5: Who was the victim of the murder?

Parsing of the questions is the really difficult part of QA. However, the usage of category names isn't something brand new in the field. See the NIST TREC Question Answering competition. The last couple of years' challenges involved a group of questions referencing a "target" and/or the previous question or previous answer to correctly formulate the current answer.

Example:
TARGET: John William King convicted of murder
Q1: How many non-white members of the jury were there?
Q3: Where was the trial held?
Q4: When was King convicted?
Q5: Who was the victim of the murder?

Parsing of the questions is the really difficult part of QA. However, the usage of category names isn't something brand new in the field. See the NIST TREC Question Answering competition. The last couple of years' challenges involved a group of questions referencing a "target" and/or the previous question or previous answer to correctly formulate the current answer.

Example:
TARGET: John William King convicted of murder
Q1: How many non-white members of the jury were there?
Q3: Where was the trial held?
Q4: When was King convicted?
Q5: Who was the victim of the murder?

Maybe it'll finally open the government's eyes to protecting their networks.

Oh, they realize it. There is a big push to have a standard secure desktop to all of the Fed's computer. The standard is good. It does everything that you'd expect for a secure desktop. Restriction of services, and admin accounts, and blocking Active X controls. Lock down the ability to connect to Windows share willy-nilly. Make sure that all the patches to software are installed in a timely fashion. (IE: Conflicker should not be infecting Federal machines, if they were following these guidelines, they would have had the patch deployed in 10 days) And the best part is (in theory anyway, I have yet to see it actually happen) that if a software vendor wants to be on GSA, they need to certify that their application can run without admin rights. And if they don't they need to document exactly why.

The problem? It was supposed to be implemented February of 20088. And outside of a few big pilot programs, nobody has the thing 100% implemented yet.

Part of the problem is that if you implement everything, you're practically guaranteed to not be able to work in your environment, so one must find and document the exceptions. If you have a crappy network/desktop practices to begin with, you'll be screwed in your deployment. Our practices were good to begin with, scoring 80% compliance, and it didn't take much to get to 90%, but that last 3% to be in the green is proving to be a killer.

There are some exceptional sysadmins out there, but they are often hogtied by anti-security regulations and expectations.

The regulations generally aren't the problem (Though just last month it was announced that Entrust encrypted email is no longer acceptable to send PII through. You have to use an encrypted USB thumbdrive. And not just any drive, A Kanagaroo drive. No BlackBox Data Travellers, no IronKeys, just these colorful Kanagroo drives, so sometimes the regs don't make sense), it's the expectations. I'm always told that "The company (I work for a subcontractor to the feds) will do everything that they can to make sure that we meet Cyber's needs". Which is great until somebody with enough political clout is inconvenienced. Fortionatly, this is becoming more and more rare, as the Feds have been backing our decisions.

Support from software vendors also suck: "It works for us, why don't you give them admin rights, that'll fix it?" Uh, not just no, HELL NO

An open letter to any hardware vendor considering making chips for these higher speed protocols:

Please add the timestamp counters needed to support IEEE-1588 Precise Timing Protocol. These counters don't add much in the way of complexity when added to the NIC, but they are VERY complex to add after the fact.

Being able to synchronize the clocks of 2 hosts to 5nS or less may seem esoteric right now, but for these sorts of transfer speeds, you are going to have a significant number of users (Test and Measurement folks like me, scientists at places like CERN and FermiLab, grid computing) who will need that kind of time sync.

http://www.ieee802.org/1/pages/802.1as.html

There you go.

An open letter to any hardware vendor considering making chips for these higher speed protocols:

Please add the timestamp counters needed to support IEEE-1588 Precise Timing Protocol. These counters don't add much in the way of complexity when added to the NIC, but they are VERY complex to add after the fact.

Being able to synchronize the clocks of 2 hosts to 5nS or less may seem esoteric right now, but for these sorts of transfer speeds, you are going to have a significant number of users (Test and Measurement folks like me, scientists at places like CERN and FermiLab, grid computing) who will need that kind of time sync.

Sure it is interesting. Lots of times you can't adequately simulate 'real world conditions' in an office LAN or even with consumer grade connectivity.

Example: At my job we operate a work-at-home business that transmits essentially a voip phone call from various locations of a certain restaurant chain to the worker's home over two dsl lines, but without the luxury of being able to 'redial'. The only DSL we can actually get in our office is too close to our datacenter (under 5 hops) to adequately simulate natural conditions.

We need to be able to make our solution able to cope with crappy lines and the only way to do that is by artifically generating latency. We had been using this old tech: http://www-x.antd.nist.gov/nistnet/index.html but it is unmaintained now and while it runs well, finding a suitable distro to run it on is troublesome in the event our nist box ever kills itself or should another such dismal fate befalls it. This type of thing would be much better albeit w/o the pretty gui ;)

I'll definately be looking into the tc command more, I had examined it the last time I needed the test but somebody finally located the working nist box before I could get too deep in the man page.

I suspect this can be done by minicom called from a cron job. Not really my area of expertise, has anyone else actually completely automated a task like this?

No no no, not "suspect" you mean "expect".

http://expect.nist.gov/

Actually, "suspect" is a pretty good Infocom text adventure.

While I applaud the Senators' efforts to assist in securing cyberspace, historical efforts to legislate cyber-security have not proven effective. (that was tough to say with a straight face) To wit, examine the Government's own record: Currently all federal agencies are required to follow strict guidelines/policy, yet the average info-security grade given by OMB, for FY2007 was a C-. How far would you get in life if your average grade was a C-? I'd guess the average Slashdotter had better than a 1.7 average.

Further, they seem to think that if NIST establishes "measurable and auditable cybersecurity standards", then all will be right with the world. NEWSFLASH - The Fed already has that for the entire GOV, and while many agencies have improved it has not shown to be the panacea they intended. According to OMB's report out 3 weeks ago(go to page 9), the DOD, the agency with the most important security concerns and highest risk (and consequently the most stringent InfoSecurity program) is failing miserably.

Funny, if you read the FISMA top page, it refers to 'cost-effective' security programs, but nowhere does it mention effective programs...

New legislation is not the answer - holding people accountable is. [to keep this relatively short I'm not going to expand on this - you know how to find the laws]

As one previous poster noted, a bunch of us posting here is not going to change anything. So, I will end this with a call to action for all Slashdotters - write a letter to your Senator and Congressman and let them know (using clear, thoughtful words) that this is an f'ing stupid idea and that they should not support it.

Find your congressman

Find your senator

AFAIK no Browser supports VRML, you need a plugin.

That's possibly the reason no-one supports it, you might as well write your 3d graphics in silverlight to get a better userbase.

Hopefully, this will get an implementation embedded in Firefox and Chrome and then we'll see widespread adoption - especially if Google makes its apps 3d.

In theory, if these drives are being used by a US government agency for encryption, then the drives need to be FIPS 140-2 certified.

In order be certified, there is a stringent list of algorithms that may be used, for both encryption and random number generation, and these algorithms need to be tested and certified themselves.

We'll have to see if the hard drive companies want to go through the headaches involved to get FIPS certification, or whether this is meant as a gimmick for consumers.

Question answering (QA) has been around as a research track for years, and quite a lot of effort has been spent in the field. See for instance http://trec.nist.gov/data/qa.html - So, is the novelty in the story that someone is trying to make a business out of it? I doubt it, because even that has been tried before, most recently with powerset.com. Of course, I assume that the business model would be "getting bought by a search giant as soon as we can", and not creating an actual competitor to google and the likes.

"Wait, NIST? You mean the guys who sit around and define the meter and mile and kilogram? ;)"

The National Institute of Standards and Technology, yes. Check out the NIST Computer Security Resource Center: http://csrc.nist.gov/ It's actually good stuff, but again, redundant with the eleventeen other US Federal agencies publishing guidance. Confusion over authority helps nothing, least of all security.

Oh, and BTW: It's actually the BIPM that defines the SI units like meter and kilogram. (BIPM = Le Bureau international des poids et mesures, the International Bureau of Weights and Measures, headquartered in France.)

Secunia states that Firefox3 has less critical issues: http://secunia.com/advisories/product/19089/

While IE6 and IE7 have moderate problems. Making IE less secure: http://secunia.com/advisories/product/11/ http://secunia.com/advisories/product/12366/

Firefox3 also has only 1 issue unpatched, while IE6 has 22 open issues.

Good. I hit a nerve. Don't fall for Secunia's misleading descriptions and understate the risk significantly. Qo re-read those "moderate" problems on MSIE and compare them to "severe" bugs on other products. Yeah, the MSIE bugs are frequently downplayed in severity.

The advisories are also hidden away for some products and lifted to the start page for others. Just try to find the MSIE advisories in the by product listing. Can't easily do it. Also notice that in the scope notes, most of the MSIE vulnerabilities expand out to include all applications which can inadvertently call MSIE through hard-coded options, such as WMP. That works out to a very large base of vulnerable applications.

Secunia's not the only one obfuscating the unsuitability of MS products. Even the US NVD is affected. None of them mention avoiding the defective product (Windows) or problem tool (MSIE). It wasn't too many years ago that mainstream magazines were talking about banning MS Outlook for the sake of security. Now even "security" specialists are changing the subject or mumbling when asked if the emperor is really wearing any clothes.

There's just not a business case to stay on the autoflagellation combination, Windows+MSIE

How can POSIX account for all the leap seconds the government decides to make up?

How can DNS account for all the top-level domains that the government decides to make up?

POSIX could account for leap seconds the same way NTP does: it gets a copy of the leap seconds file and knows ahead of time to count it off. Yes, the algorithm needs a look-up table. Deal with it. :-)

When a leap second occurs, all clocks are moved forwards or backwards by a second

No, when a leap second occurs, all clocks (in theory) count an extra second for that minute. 18:59:58, 18:59:59, 18:59:60, 19:00:01 (depending on your time zone). Of course our cheap wall clocks and wrist watches don't do that, but that's they way "real" clocks count off a leap second.

The point of the comic is that there's no *practical* difference between, say, 128-bit encryption and 4096-bit encryption [...]

There's a huge difference. When you see numbers like "128-bit," you're dealing with a symmetric encryption algorithm (e.g., AES). When you see numbers like "4096-bit," you're dealing with an asymmetric algorithm (e.g., RSA).

See the NIST Recommendation for Key Management (PDF), page 63. For example, to get RSA that is "equivalently" secure (for some predicted meaning of equivalent) to AES-128, you need a 3072-bit key. The table is explained on page 62.

As an aside, the comparably small key sizes that asymmetric elliptic curve cryptograph (ECC) can use, illustrated on page 63, are one of the reasons that ECC is so valuable.

Sorry, but you're wrong.

Celsius temperature is an SI derived unit, so it is nowhere near obsolete. The inch, on the other hand, is indeed as obsolete as Margaret Thatcher.

See here, for instance.

in what way is the "second" metric?

How about this way?

But then there's all the other installation methods including RPC.

If you're going to roll out a large-scale installation, you do the install on one box, get everything tweaked just the way you need it, then ghost it to the rest of the boxes. I'd think it was clear by now that turning off autorun should be one of the tweaks you do by reflex before ghosting.

Better yet, use Active Directory to deploy GPO's. If you don't know where to begin, grab the ones that NIST developed. (About 1/2 way down the page, find the table with GPO's)

Disclaimer: If you blindly install these, you're almost certain to break your network (but they do have a VM with the settings that you can download and test with). Things that are known to have problems: Some websites with 128bit encryption. NTLMV2 is enforced and breaks Windows 9x compatibility. The RDP client with SP3 starts having issues connecting to machines that don't have the exact same settings. Common diagnostic commands get their rights stripped so normal users can't use them (ie: reg, regedit, reged32, runas, arp, at and about 20 others). A few other odds and ends that I don't remember right now. Oh, yea: and Autorun is disabled!

I can't see where anyone in this thread has said otherwise, nor am I aware of any attempts to redefine "Giga" as an SI prefix to mean anything else.

You're unaware that GB means 10^9 bytes while others think it should mean 2^30 bytes? In all cases, the giga- or G prefix means 10^9, while the gibi- or Gi prefix should be used for 2^30. http://en.wikipedia.org/wiki/Binary_prefix

(If you mean as in Gigabyte, then that's a completely different issue, since byte is not an SI unit. Unfortunately we are fighting against recent attempts to hijack it to a new and wrong numerical definition, simply to make it the same as the usage for SI units.)

It's not a different issue, according to NIST, IEC, NBS, IUPAC, and others. The issue has nothing to do with whether the unit being prefixed is SI or not, and everything to do with avoiding ambiguity (what about giga-dollars, for instance). Actually, the instance of megabytes and so forth is explicitly and clearly covered by the standards authorities. From the abovementioned wiki page: "Under this recommendation, the SI prefixes should only be used in the decimal sense: kilobyte and megabyte denote one thousand bytes and one million bytes respectively, while kibibyte and mebibyte denote 1,024 bytes and 1,048,576 bytes respectively. This recommendation has since been adopted by some other leading national and international standards, which now state that the prefixes k, M and G should always refer to powers of ten, even in the context of information technology." You can look up the SI definitions in French and English at http://www1.bipm.org/utils/common/pdf/si_brochure_8.pdf or if you're willing to pay, you can get IEEE 260.1-2004 which standardized kibi- gibi- and so forth. The "for idiots" summary is available from NIST http://physics.nist.gov/cuu/Units/binary.html

So disk drive manufacturers and others using GB to mean 10^9 bytes are actually correct. Those howling that it should mean 2^30 bytes are actually wrong. In every case.

And fail when the known valid source is unreachable?

Imagine a game that comes with a USB security dongle. One of the items on this dongle is a real-time clock with a radio designed to receive WWVB, the radio station that $20 "atomic" clocks pick up. Under what circumstances within DVD Region 1 would this signal be less reachable than the game publisher's NTP server?

Only 110 millibits per second? I think you probably meant 1TB and 110 MB/s. Case matters in SI and IEC units.

The US National Archives for Preservation and Archives Professionals page contains much information, including that which is specific to time capsules.

Northeast Document Conservation Center is another good resource with guidance pertaining to specific types of materials.

NIST's PDF guide Care and Handling of CDs and DVDs contains best-practices for optical media storage/handling.

The general procedure I use is:

1) Get and install Debugging Tools for Windows for your platform.

2) Run kernrate.exe from the resource kit tools to determine if the problem is an I/O or CPU limit. (See here for how to get symbolic usage information.) If you do not see anything hogging the CPU, it's an I/O problem and you should go to step 5.

3) It's a CPU problem, so use the information from kernrate to figure out who's bogarting the CPU. If the process is services.exe, rundll32.exe, or System, you need to use something like Process Explorer to determine which file actually contains the code which is executing.

4) If that doesn't work, it may really be an I/O problem or a rootkit. If you suspect a rootkit, your main options are reinstallation or forensic analysis using something like a boot CD, TSK, and the NIST hash database to audit your machine for bad files.

5) Run Process Monitor and see who's responsible for all the I/O.

6) If that doesn't reveal anything, it might be a driver problem. Use Process Explorer to see if you have excessive DPCs (the Windows equivalent of a top half interrupt handler). Use kernrate to zoom in and see which driver is causing them.

Downadup and other such similar worms exploit a vulnerability in the Windows Server service: Server Service Vulnerability -- CVE-2008-4250

The vulnerability is detailed by October 23rd's Microsoft Security Bulletin MS08-067.

But seriously if you really want to know how to erase your media here are the instructions for the US government. For destroying hard drives they recommend you "disintegrate, shred, pulverize, incinerate" (p19) the hard drive

You left out the most important last step: "nuke it from orbit, it's the only way" (p20) to be sure.

Yes, a two year old with Torx for fingers. But seriously if you really want to know how to erase your media here are the instructions for the US government http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf. For destroying hard drives they recommend you "disintegrate, shred, pulverize, incinerate" (p19) the hard drive

I personally find it very telling that the US government turned down Blowfish despite larger keysize, longer keyspace initialization, non-fixed S-boxes, and better performance, compared to AES.

You can turn off your conspiracy detector. First, Blowfish wasn't allowed to be used in AES since the call for algorithms required it to handle a block size of 128 bits.

Twofish was submitted but Rijndael was selected because of it's performance in the different types of hardware that they tried. There is a Report on the Development of the Advanced Encryption Standard [PDF warning], that provides a performance comparison, (by rating it I, II or III), of the various algorithms submitted for AES using a variety of hardware and environments, like 8-bit C and Assembler. (Figures 2, 3 and 4 in the paper.)

Also, the NSA approved AES for use on U.S. Top Secret information. They would hardly do that if there was a known method of cracking it.