Slashdot Mirror

These are what systems are required to do in the way of security measures, as defined by the Federal Information Processing Standards, the Orange Book and the Common Criteria.

A lot of the documentation can be found at the Information Assurance Support Environment website, Policy and Guidance

To summarize, information that is labelled "Secret" can only be stored on a machine that - in the Orange Book system - is classed as B3 or better. The use of security labeling and a mox of host-level and network-level mandatory access controls is supposed to ensure that this is actually mandated at the OS level on each machine and between machines. B3 is equal to the more modern Commmon Criteria EAL4.

(It is impossible, in theory, to transfer information that is classified at one level into a lower classification, on the same machine or by going through a series of machines. To be able to do so is a violation.)

To be given an EAL4 rating, that precise combination of hardware and software MUST be tested by an approved laboratory and shown to meet all of the criteria.

Further, as noted on the FIPS website: "With the passage of the Federal Information Security Management Act of 2002, there is no longer a statutory provision to allow for agencies to waive mandatory Federal Information Processing Standards (FIPS)."

• Minimum Security Requirements for Federal Information and Information Systems (FIPS 200)
• Standards for Security Categorization of Federal Information and Information Systems (FIPS 199)
• Standard Security Label for Information Transfer (FIPS 188)

Mandated Criteria, Rainbow Series and Related

• Computer Security Requirements (CSC-STD-003-85)
• Security Requirements for Automated Information Systems (AISs)
• A Guide to Understanding Configuration Management in Trusted Systems (Orange Book, Rainbow Series)

Mandated Criteria, Common Criteria

• Common Criteria for Information Technology Seciryt Evaluation, Part 1
• Common Criteria for Information Technology Seciryt Evaluation, Part 2
• Common Criteria for Information Technology Seciryt Evaluation, Part 3
• Comon Methodology for Information Technology Security Evaluation

These are NOT optional. These are Federally-mandated requirements. If Manning's computer did not meet these standards, it was NOT authorized to be on the network and the machines that transferred classified information to it were NOT authorized to do so.

These are what systems are required to do in the way of security measures, as defined by the Federal Information Processing Standards, the Orange Book and the Common Criteria.

A lot of the documentation can be found at the Information Assurance Support Environment website, Policy and Guidance

To summarize, information that is labelled "Secret" can only be stored on a machine that - in the Orange Book system - is classed as B3 or better. The use of security labeling and a mox of host-level and network-level mandatory access controls is supposed to ensure that this is actually mandated at the OS level on each machine and between machines. B3 is equal to the more modern Commmon Criteria EAL4.

(It is impossible, in theory, to transfer information that is classified at one level into a lower classification, on the same machine or by going through a series of machines. To be able to do so is a violation.)

To be given an EAL4 rating, that precise combination of hardware and software MUST be tested by an approved laboratory and shown to meet all of the criteria.

Further, as noted on the FIPS website: "With the passage of the Federal Information Security Management Act of 2002, there is no longer a statutory provision to allow for agencies to waive mandatory Federal Information Processing Standards (FIPS)."

• Minimum Security Requirements for Federal Information and Information Systems (FIPS 200)
• Standards for Security Categorization of Federal Information and Information Systems (FIPS 199)
• Standard Security Label for Information Transfer (FIPS 188)

Mandated Criteria, Rainbow Series and Related

• Computer Security Requirements (CSC-STD-003-85)
• Security Requirements for Automated Information Systems (AISs)
• A Guide to Understanding Configuration Management in Trusted Systems (Orange Book, Rainbow Series)

Mandated Criteria, Common Criteria

• Common Criteria for Information Technology Seciryt Evaluation, Part 1
• Common Criteria for Information Technology Seciryt Evaluation, Part 2
• Common Criteria for Information Technology Seciryt Evaluation, Part 3
• Comon Methodology for Information Technology Security Evaluation

These are NOT optional. These are Federally-mandated requirements. If Manning's computer did not meet these standards, it was NOT authorized to be on the network and the machines that transferred classified information to it were NOT authorized to do so.

These are what systems are required to do in the way of security measures, as defined by the Federal Information Processing Standards, the Orange Book and the Common Criteria.

A lot of the documentation can be found at the Information Assurance Support Environment website, Policy and Guidance

To summarize, information that is labelled "Secret" can only be stored on a machine that - in the Orange Book system - is classed as B3 or better. The use of security labeling and a mox of host-level and network-level mandatory access controls is supposed to ensure that this is actually mandated at the OS level on each machine and between machines. B3 is equal to the more modern Commmon Criteria EAL4.

(It is impossible, in theory, to transfer information that is classified at one level into a lower classification, on the same machine or by going through a series of machines. To be able to do so is a violation.)

To be given an EAL4 rating, that precise combination of hardware and software MUST be tested by an approved laboratory and shown to meet all of the criteria.

Further, as noted on the FIPS website: "With the passage of the Federal Information Security Management Act of 2002, there is no longer a statutory provision to allow for agencies to waive mandatory Federal Information Processing Standards (FIPS)."

• Minimum Security Requirements for Federal Information and Information Systems (FIPS 200)
• Standards for Security Categorization of Federal Information and Information Systems (FIPS 199)
• Standard Security Label for Information Transfer (FIPS 188)

Mandated Criteria, Rainbow Series and Related

• Computer Security Requirements (CSC-STD-003-85)
• Security Requirements for Automated Information Systems (AISs)
• A Guide to Understanding Configuration Management in Trusted Systems (Orange Book, Rainbow Series)

Mandated Criteria, Common Criteria

• Common Criteria for Information Technology Seciryt Evaluation, Part 1
• Common Criteria for Information Technology Seciryt Evaluation, Part 2
• Common Criteria for Information Technology Seciryt Evaluation, Part 3
• Comon Methodology for Information Technology Security Evaluation

These are NOT optional. These are Federally-mandated requirements. If Manning's computer did not meet these standards, it was NOT authorized to be on the network and the machines that transferred classified information to it were NOT authorized to do so.

These are what systems are required to do in the way of security measures, as defined by the Federal Information Processing Standards, the Orange Book and the Common Criteria.

A lot of the documentation can be found at the Information Assurance Support Environment website, Policy and Guidance

To summarize, information that is labelled "Secret" can only be stored on a machine that - in the Orange Book system - is classed as B3 or better. The use of security labeling and a mox of host-level and network-level mandatory access controls is supposed to ensure that this is actually mandated at the OS level on each machine and between machines. B3 is equal to the more modern Commmon Criteria EAL4.

(It is impossible, in theory, to transfer information that is classified at one level into a lower classification, on the same machine or by going through a series of machines. To be able to do so is a violation.)

To be given an EAL4 rating, that precise combination of hardware and software MUST be tested by an approved laboratory and shown to meet all of the criteria.

Further, as noted on the FIPS website: "With the passage of the Federal Information Security Management Act of 2002, there is no longer a statutory provision to allow for agencies to waive mandatory Federal Information Processing Standards (FIPS)."

• Minimum Security Requirements for Federal Information and Information Systems (FIPS 200)
• Standards for Security Categorization of Federal Information and Information Systems (FIPS 199)
• Standard Security Label for Information Transfer (FIPS 188)

Mandated Criteria, Rainbow Series and Related

• Computer Security Requirements (CSC-STD-003-85)
• Security Requirements for Automated Information Systems (AISs)
• A Guide to Understanding Configuration Management in Trusted Systems (Orange Book, Rainbow Series)

Mandated Criteria, Common Criteria

• Common Criteria for Information Technology Seciryt Evaluation, Part 1
• Common Criteria for Information Technology Seciryt Evaluation, Part 2
• Common Criteria for Information Technology Seciryt Evaluation, Part 3
• Comon Methodology for Information Technology Security Evaluation

These are NOT optional. These are Federally-mandated requirements. If Manning's computer did not meet these standards, it was NOT authorized to be on the network and the machines that transferred classified information to it were NOT authorized to do so.

Who are these guys anyway? You expect better from NIST.

They are the same guys who came up with this piece of scientific work

No. The term "cloud" may have started as a buzz word but it has taken some serious shape in less than a year. For a serious, comprehensive definition, check a short document posted by NIST.

In short, "Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction".

It doesn't have to be necessarily hosted on external providers. It may very well be an internal, Private Cloud. And if it's built on top of open standards such as the vCloud API, you may end up with vApps that can be moved from internal to external clouds and back, as well as hybrids.

Insist that they conform to Federal Information Processing Standards (FIPS).

Air gapping (as others have mentioned) is a great idea, but not always feasible. Remote access to plants is sometimes needed for emergencies.

Have a look at the Computer Security Resource Centre. NIST IR 7628 covers cyber security for the smart grid, and much of that is applicable to water and sewerage plants.

The report, 21 Steps to Improve Cyber Security of SCADA Networks, is also worth a read.

My opinions, based on power station and substation SCADA are: don't use one vendor for everything, have two levels of firewall from different vendors at the remote site, turn off or block services that are not needed from every device, have reporting and audit trails that are reviewed, and if management want reporting, do it through a one way connection to an intermediate system (one way Ethernet, RS232, RS485 or read only shared storage).

The clock is bad implementation. It should use the incoming radio signal to determine when DST is in effect, not a preset table. Sigh. Things are so bad that NIST had to come up with implementation guidelines for designers of those clocks. It is an interesting read -- most of the cheap WWVB-controlled clocks miss most of the recommendations. Case in point: my wife's clock. The things it got wrong:

1. Use of a satellite icon to mark when it's synchronized: check.
2. Insufficient signal consistency checking: yep -- every 2-3 months it completely garbles its time during synchronization.
3. Synchronization at wrong time of day: check -- time should depend on the time zone *and* time of year. The default of midnight is poor.
4. No way of turning off DST: check.
5. Display delay: check - up to 1.5 seconds off right after sync is way too much.
6. Signal quality display -- none: check.
7. Doesn't allow selection from the minimum of 7 time zones (HAST, AKST, PST, MST, CST, EST, AST): check.

I'd also add to it that since the clock has a fairly accurate temperature sensor (to within 0.2C from 10C to 50C -- I checked myself), it could easily temperature-compensate its oscillator. Moreover, it could also compensate longer-term drift of its oscillator against the WWVB, thus easily improving unsynchronized accuracy by say two orders of magnitude. It's all in the firmware, so there's little per-unit cost other than having to amortize NRE.

I haven't checked how it's implemented (MCU vs. custom silicon), but these days implementing such a clock pretty much means that you use some low-power, cheap-in-quantity MCU and do the demodulation and decoding in software, and that can be quite elaborate since the bandwidth is so low. Heck, such a clock could easily interface with pretty much all LF time code stations anywhere on Earth -- they all are in the 40-80kHz band.

NIST Smart Grid Interoperability Panel Cyber Security Working Group.

You're completely right, and thanks for adding this clarification. If you want to get a bit more of an idea of what is involved, start looking here.

I could be wrong here, but I checked the links in the story and couldn't find any confirmation that anybody really thinks IP over powerlines is part of the Smart Grid.

No, really look at this:

http://csrc.nist.gov/publications/history/myer80.pdf

I had a fellow Researcher send this to me this morning - it blows the lid off of what I've been speaking (LOUDLY) and writing about for years - here and other places, basically Subversionhack:

http://subversionhack.livejournal.com/

https://tagmeme.com/subhack/a/

^ 2nd site has Certificate Expiration problem ^

Chertoff article:

"Chertoff told ZDNet UK at the conference that cyberattacks on critical national infrastructure could put thousands of people at risk. "I can envision attacks with catastrophic consequences, with serious loss of life," said Chertoff. "If someone took down an air-traffic control system, we would have devastating loss of life."

"Cold War" is a bit extreme, Red Teams would be a better response.
When you have a hack within the truly elite league such as (the) Subversion(hack) you really need to envision the possibilities of a thousand little fires all within the confines of your neighborhood - honestly.

This NAVY paper of 1980 should get you up to speed.
If you have a Slashdot account, review my post on this and things will become a bit more clear.

The first of my links should give you a good over all.

testing for singlethreaded performance.....

if you have an Athlon II X4 of any speed, please run:

cpumark99 on it (if you can find it), and you might get the fastest score in safe mode...

the java benchmark from NIST on it http://math.nist.gov/scimark2/run.html

and if you can get calc.exe from windows XP, time a factorial of 100,000!

(the factorial function in the new calculator that comes with win7 chokes on big factorials, and all the scores i've accumulated are using calc.exe from xp)

Obviously you are a troll, and are not involved in any kind of Internet engineering, etc., but have an unqualified opinion.
I wasn't going to respond to your drivel, then I realized someone may read your comments, and get the wrong idea.

A good number of IT admins are trying to prepare for the IPv4 exhaustion / IPv6 migration issue for the future, and at least some governments are as well. The problems are far reaching, and extremely complex. There are no obvious answers here, which is why so many people recommend to get started planning (especially for companies who have hardware/software upgrade cycles of years). Additionally, nobody "owns" the Internet to make executive decisions for the world-wide Internet.
For someone reading this, and wanting to know how to get started looking up valid information:

First, know there is support available. Actually, there is a LOT of support if you want to look at how IPv6 will affect you/your business. Some paid, lots free (but with a higher learning curve for the unititiated, of course). Google is your friend.
Second, check out the many RFC's for IPv6 operations that the IETF has (http://tools.ietf.org/wg/v6ops/). There is a lot of good stuff there, covering many of the many technical issues/complaints brought up from experience, and even some of the issues brought forward on this forum page.
Third, some governments have put out documents on IPv6. In the U.S., NIST has been putting out a lot of information and guidelines:
http://www.antd.nist.gov/usgv6-v1-draft.pdf
http://csrc.nist.gov/publications/drafts/800-119/draft-sp800-119_feb2010.pdf
http://www.rti.org/publications/abstract.cfm?pub=6578 (This one covers the economic impact of IPv4, NAT, IPv6 adoption, etc....really good for someone wishing to get some hard numbers on what to expect, or how much NAT REALLY costs).

Anonymous because I don't feel like signing in over airport wifi....

Obviously you are a troll, and are not involved in any kind of Internet engineering, etc., but have an unqualified opinion.
I wasn't going to respond to your drivel, then I realized someone may read your comments, and get the wrong idea.

A good number of IT admins are trying to prepare for the IPv4 exhaustion / IPv6 migration issue for the future, and at least some governments are as well. The problems are far reaching, and extremely complex. There are no obvious answers here, which is why so many people recommend to get started planning (especially for companies who have hardware/software upgrade cycles of years). Additionally, nobody "owns" the Internet to make executive decisions for the world-wide Internet.
For someone reading this, and wanting to know how to get started looking up valid information:

First, know there is support available. Actually, there is a LOT of support if you want to look at how IPv6 will affect you/your business. Some paid, lots free (but with a higher learning curve for the unititiated, of course). Google is your friend.
Second, check out the many RFC's for IPv6 operations that the IETF has (http://tools.ietf.org/wg/v6ops/). There is a lot of good stuff there, covering many of the many technical issues/complaints brought up from experience, and even some of the issues brought forward on this forum page.
Third, some governments have put out documents on IPv6. In the U.S., NIST has been putting out a lot of information and guidelines:
http://www.antd.nist.gov/usgv6-v1-draft.pdf
http://csrc.nist.gov/publications/drafts/800-119/draft-sp800-119_feb2010.pdf
http://www.rti.org/publications/abstract.cfm?pub=6578 (This one covers the economic impact of IPv4, NAT, IPv6 adoption, etc....really good for someone wishing to get some hard numbers on what to expect, or how much NAT REALLY costs).

Anonymous because I don't feel like signing in over airport wifi....

Rob Rivest presented on this topic - his position was clear: "The risks of "internet voting" more than negate any possible benefits from an increase in franchise." Reference: http://csrc.nist.gov/groups/ST/UOCAVA/2010/Presentations/RIVEST_2010-08-05-uocava.pdf/

Why would you want to give a kid a ruler with inches on it in the first place?

To be serious, all decent science programmes do use SI units including the US government and UK government.

Of course, engineering, construction trades, and commerce in some countries still see common usage of non-standard units in popular (lay) life.

If you can't answer "When will each of the next 10 leap seconds be?" and "When were the last 10 leap seconds?" then you are pretty much fucked from a programming standpoint of 'handling' it in any sane manner using common time encodings, which use a count of intervals (usually seconds, or milliseconds) since some specific date and time.

ftp://time.nist.gov/pub/leap-seconds.list is a publicly available file that lists all announced leap seconds (past and future), designed for use in time conversion functions. And yes, it does need to be periodically refreshed, just like the zoneinfo database.

Life would be much easier if all manufacturers adjusted for leap seconds in their localtime() and gmtime() functions, rather than in the hardware clocks and their time() functions.

If one is using SI units, then it is appropriate to measure things in kilograms.

R is an excellent language to learn for just about every field. It's ability to import and export data to MS based resources such as Access, Excel, MS-SQL and other non-MS sources makes it a versital tool. It's commerical parent is S-PLUS and is nearly syntax identical with minor variations. Buy the book, use the tool, impress your Eve Online players by pinning down the July Tritanium prices and hitting the weekly averages within .5 ISK by doing time series analysis using regression plus ARIMA on the residuals. Find out cool things like Hulkageddon impacts frigate prices more then exhumers and MORE! FUN FOR THE WHOLE FAMILY (Except your big sister because she's icky and into boys....) For those what want to do google searches but find 'R' difficult there is the rseek.org site and a few quick links to get you started while you wait for the nutshell book to arrive in the mail. R Intro : http://www.itc.nl/~rossiter/teach/R/RIntro_ov.pdf Programming in R: http://manuals.bioinformatics.ucr.edu/home/programming-in-r R Graph Gallery: http://addictedtor.free.fr/graphiques/ Big Resource I use: http://www.math.yorku.ca/SCS/StatResource.html The Little Handbook: http://www.tufts.edu/~gdallal/LHSP.HTM The Big N: http://www.itl.nist.gov/div898/handbook/ There are hundreds of PDF references out there that can help as well, too many to list. Good luck, have fun.

Talking about dis???

lwp-download in libwww-perl before 5.835 does not reject downloads to filenames that begin with a . (dot) character, which allows remote servers to create or overwrite files via (1) a 3xx redirect to a URL with a crafted filename or (2) a Content-Disposition header that suggests a crafted filename, and possibly execute arbitrary code as a consequence of writing to a dotfile in a home directory.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-2253

Seems a waste to develop a new rocket when 75 milliTeslas (75 mT) of magnetic flux density in the form of a neodymium magnet doesn't weigh much.

One can only assume that the authors wished to express the SI related unit of 75 tonnes (75 t) or 75000 kg. Even in the US this unit is denoted by "t"

"Metric System of Measurement: Interpretation of the International System of Units for the United States" (PDF). Federal Register 63 (144): 40333–40340. July 28, 1998. 63 FR 40333.

Don't they know MD5 is deprecated. They should be using SHA-1. Off to a disappointing start already...

SHA-1 is deprecated, too. They should be using SHA-2, or if they really want to show off SHA-3.

That is what it looked like to me as well, but I found the actual paper, and he is creating his "non square-pixel" image from a larger image, not upscaling it from a smaller one. In other words, it is basically just a form of poor-man's compression where you replace each 6x6 block with one of 8 decompositions containing two coefficients each.

First, here's the actual paper, since it clarifies what exactly he's suggesting and doesn't seem to be linked anywhere in the article.

It's not a suggestion that we start using non-square pixels for displays or cameras or scanners or what not, though he's certainly not being very clear about anything and the reporting on this is just making matters worse. What the paper proposes is a method where:
1) The image is split into 6x6 blocks
2) For each block, you go over the four rotations of the two following two-section masks:
The triangular mask:
ABBBBB
AABBBB
AAABBB
AAAABB
AAAAAB
AAAAAA
The rectangular(ish) mask:
BBBBBB
BBBBBB
BBBAAA
AAAAAA
AAAAAA
AAAAAA
for a total of eight effective masks, and average the values under each section, resulting in two values, A and B.
3) For the mask and rotation that has the largest difference between A and B, you output the mask, the rotation, and the A and B values, resulting in 19 bits from a 6x6 (288 bits) block.

Though he talks of non-square pixels and whatnot, it's really just a compression algorithm. A really stupid one. Basically it's a bad variation of vector quantization, with lots of baffling details. Why 6x6 blocks? Why those specific masks? Why are you maximizing contrast instead of minimizing error like any sane person would do, WHY? There's no rationale given for any of these choices, not theoretical, not empirical, not even subjective.

The same sort of rigor extends to his comparison, where he compares his compression algorithm to, instead of, say, another compression algorithm, the image apparently simply downscaled and then scaled back up. And not even with a halfway decent resampling algorithm, but with nearest neighbour. Not to mention that the "non-square pixels" version has 2.375 times as many bits to work with. If he'd done a comparison to a reasonably modern compression algorithm like JPEG, the results would be much less favorable to him.

tl;dr Some old guy put together his My First Compression Algorithm kit and it's being treated like a revolution in graphics by ignorant reporters. Nothing to see here, move along.

http://nvl.nist.gov/pub/nistpubs/jres/115/3/V115.N03.A03.pdf

I don't claim to know much about quantum physics but I do know the masses involved are almost infinitesimally small and any measurement of them is likely to be incorrect as our methods of measuring are far from perfect.

The mass defect is the basis of both nuclear fission and nuclear fusion power generation, and the atomic masses are known to quite a high accuracy these days. Go look at NIST, their physical reference data has the electron, proton, neutron and various atomic masses with the uncertainties, with references to the data sources.

>(still, where is the AES equivalent of a secure hash?)
here:
http://csrc.nist.gov/groups/ST/hash/timeline.html

• A gas is a compressible fluid.

  But it cannot be treated as such when the density gets too low. You couldn't treat the edge of the atmosphere as a fluid. I don't care what it is when I use a CFD, only what it behaves like.

  • The most general solvers are the most handicapped. Even the ridiculously costly commercial solvers (Ansys, Fluent, etc.) solve a limited number of problems. I was working on a project that attempted to numerically simulate the effect of electromagnetic waves on the brain. Obviously, you need to solve the Maxwell's equations in horrible medium that is your brain. That's when I realized how woefully indadequate the commercial solvers (that claim to simulate the problem) are.

  My brain's a medium? I thought I heard some dead people in there. :)

  Seriously, I entirely agree. I don't for a moment pretend that I'm anything like up enough on PDEs or high-end maths problems (it's been a while) to identify the best packages either. The best I can do is say such software exists. I'll list here the packages I list and use - not just for PDEs but for maths and logic problems as a whole. I'll leave it to you and others skilled in the subject to pass judgement on their quality.

  • ATLAS - A nice, optimized BLAS (Basic Linear Algebra System) implementation
  • HOL4 - Higher Order Logic proof assistant
  • Hypre - Preconditioner for linear equation solvers
  • LAPack - Linear Algebra Package that runs over BLAS
  • ScaLAPack - Subset of LAPack optimized for highly parallel computers
  • Overture - A PDE solver
  • PHAML - A PDE solver for 2D elliptic partial differential equations
  • SUNDIALS - An expansive (and rather nice) PDE solver
  • VSIPL++ - Nice little signal processing library

Pursuant to Title 17 USC 105, the National Institute of Standards and Technology (NIST), United States Department of Commerce, is authorized to receive and hold copyrights transferred to it by assignment or otherwise. Authors of the works appearing in the Digital Library of Mathematical Functions (DLMF) have assigned copyright to the works to NIST, United States Department of Commerce, as represented by the Secretary of Commerce.

You don't need to change user-agent. Take a look at the customization page http://dlmf.nist.gov/help/customize. I wish all sites had something like that.

No, all sites should not have something like this. End users should not have to do something special like this to work around the fact that IE doesn't support MathML properly. (IE requires a plugin, and even with the plugin, it doesn't support standard mathml; web authors have to make special IE-only versions of their pages with nonstandard kludges written in.) The best solution is for IE to die. The second best solution is for Opera users to contact the webmaster at nist.gov and ask them to configure their server so it recognizes recent versions of Opera as having mathml, in the same way it recognizes recent versions of Firefox.

Opera has had MathML support since 9.5, but it looks like this page serves up PNGs for equations to Opera unless the user-agent is changed. When the user-agent is changed, MathML is served up, but the rendering is off, with little blank boxes dotted around (see this page for example: http://dlmf.nist.gov/2.7 ). Anyone else getting similar results?

This is just one of many examples of the pain and suffering caused by MS's failure to implement the MathML standard in IE. Webmasters shouldn't have to special-case browsers like this, but they're forced to, because they can't just afford to have the page not work for IE users. When you have to special-case different browsers and version numbers of browsers, it's inevitable that you'll get problems like this. Every new browser that is every written will not get served mathml by a site like this, until someone finally gets in touch with the webmaster of the site and gets him to add a special case for that browser. The only solution I can think of is to make it a federal crime to use IE.

You don't need to change user-agent. Take a look at the customization page http://dlmf.nist.gov/help/customize. I wish all sites had something like that.

Opera has had MathML support since 9.5, but it looks like this page serves up PNGs for equations to Opera unless the user-agent is changed. When the user-agent is changed, MathML is served up, but the rendering is off, with little blank boxes dotted around (see this page for example: http://dlmf.nist.gov/2.7 ). Anyone else getting similar results?

-molo

Most of work involves commodity certification & accreditation (C&A) that involves the following:

Phase 1
a "system owner" (Govt IT manager) has staff prepare documentation of the security controls implemented on a "system" (Logical grouping of computers). The security controls are in NIST 800-53, this is FISMA in action.
C&A process http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf
NIST Controls http://csrc.nist.gov/publications/nistpubs/800-53-Rev2/sp800-53-rev2-final.pdf
NIST Audit process http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-53-A%20Rev.%201

Phase 2
A certification agent comes in, assesses the system using tools and configuration analysis. This is heavily slanted towards audit, instead of true security analysis.

Phase 3
A senior executive (Authorizing official) makes a decision about the risk acceptability of the system to operate, and may make the system owner do corrective action. The system then moves into continuous monitoring (phase 4).

That is how certification and accreditation operates in theory. Now I am going to tell you how the system is gamed.

During Phase 1, it implies you actually have competent IT security professionals on hand, performing work for the system owner. This is a false assumption. Most system owners don't know security, nor do their staff.

Phase 2 - First of all, have the certification agent companies don't understand security. They can talk the talk (CISSP) but have no solid IT / IT security expertise (not security testers). Many certification agents will not even test systems. They play a game of bringing in cheap staff or running vulnerability scanners then passing them off as "penetration tests". The amount of utter garbage in the field is amazing. Even more so are the reports they write up are audit garbage. If you asked most certification agents about a security methodology, they haven't heard of the OSSTMM or similar. They use NIST 800-53A (heavily audit driven) then they write up meaningless reports, equating technical weaknesses as just as relevant as a gap in a policy.

Phase 3 - The vast majority of government executives are clueless when it comes to IT. They know a little bit, like the name of an operating system (Linux - buzzword - yay!) but not much else. So, they are easily led astray. Most will allow a system to operate regardless of how bad it is, based on a horrible security review performed by incompetent certification agents, on a package made by the almost as clueless system owner and his staff.

After a system gets an authorization to operate, many staffs stop doing all security for 3 years, til the next C&A comes around.

It is not uncommon for a federal cabinet level agency to have 300+ systems, with 300+ system owners, with 300+ completely separate, unique and underfunded security implementations that have more holes than swiss cheese.

If you notice, what is missing from above is actually rigorous security analysis. Code is rarely audited. Configurations are rarely checked 100%. Policy is viewed as important as technical controls. Most testing is a wash. Penetration tests are vulnerability scans by nitwits.

And you wonder why the Chinese are plundering the US govt on a daily basis?

Most of work involves commodity certification & accreditation (C&A) that involves the following:

Phase 1
a "system owner" (Govt IT manager) has staff prepare documentation of the security controls implemented on a "system" (Logical grouping of computers). The security controls are in NIST 800-53, this is FISMA in action.
C&A process http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf
NIST Controls http://csrc.nist.gov/publications/nistpubs/800-53-Rev2/sp800-53-rev2-final.pdf
NIST Audit process http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-53-A%20Rev.%201

Phase 2
A certification agent comes in, assesses the system using tools and configuration analysis. This is heavily slanted towards audit, instead of true security analysis.

Phase 3
A senior executive (Authorizing official) makes a decision about the risk acceptability of the system to operate, and may make the system owner do corrective action. The system then moves into continuous monitoring (phase 4).

That is how certification and accreditation operates in theory. Now I am going to tell you how the system is gamed.

During Phase 1, it implies you actually have competent IT security professionals on hand, performing work for the system owner. This is a false assumption. Most system owners don't know security, nor do their staff.

Phase 2 - First of all, have the certification agent companies don't understand security. They can talk the talk (CISSP) but have no solid IT / IT security expertise (not security testers). Many certification agents will not even test systems. They play a game of bringing in cheap staff or running vulnerability scanners then passing them off as "penetration tests". The amount of utter garbage in the field is amazing. Even more so are the reports they write up are audit garbage. If you asked most certification agents about a security methodology, they haven't heard of the OSSTMM or similar. They use NIST 800-53A (heavily audit driven) then they write up meaningless reports, equating technical weaknesses as just as relevant as a gap in a policy.

Phase 3 - The vast majority of government executives are clueless when it comes to IT. They know a little bit, like the name of an operating system (Linux - buzzword - yay!) but not much else. So, they are easily led astray. Most will allow a system to operate regardless of how bad it is, based on a horrible security review performed by incompetent certification agents, on a package made by the almost as clueless system owner and his staff.

After a system gets an authorization to operate, many staffs stop doing all security for 3 years, til the next C&A comes around.

It is not uncommon for a federal cabinet level agency to have 300+ systems, with 300+ system owners, with 300+ completely separate, unique and underfunded security implementations that have more holes than swiss cheese.

If you notice, what is missing from above is actually rigorous security analysis. Code is rarely audited. Configurations are rarely checked 100%. Policy is viewed as important as technical controls. Most testing is a wash. Penetration tests are vulnerability scans by nitwits.

And you wonder why the Chinese are plundering the US govt on a daily basis?

Most of work involves commodity certification & accreditation (C&A) that involves the following:

Phase 1
a "system owner" (Govt IT manager) has staff prepare documentation of the security controls implemented on a "system" (Logical grouping of computers). The security controls are in NIST 800-53, this is FISMA in action.
C&A process http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf
NIST Controls http://csrc.nist.gov/publications/nistpubs/800-53-Rev2/sp800-53-rev2-final.pdf
NIST Audit process http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-53-A%20Rev.%201

Phase 2
A certification agent comes in, assesses the system using tools and configuration analysis. This is heavily slanted towards audit, instead of true security analysis.

Phase 3
A senior executive (Authorizing official) makes a decision about the risk acceptability of the system to operate, and may make the system owner do corrective action. The system then moves into continuous monitoring (phase 4).

That is how certification and accreditation operates in theory. Now I am going to tell you how the system is gamed.

During Phase 1, it implies you actually have competent IT security professionals on hand, performing work for the system owner. This is a false assumption. Most system owners don't know security, nor do their staff.

Phase 2 - First of all, have the certification agent companies don't understand security. They can talk the talk (CISSP) but have no solid IT / IT security expertise (not security testers). Many certification agents will not even test systems. They play a game of bringing in cheap staff or running vulnerability scanners then passing them off as "penetration tests". The amount of utter garbage in the field is amazing. Even more so are the reports they write up are audit garbage. If you asked most certification agents about a security methodology, they haven't heard of the OSSTMM or similar. They use NIST 800-53A (heavily audit driven) then they write up meaningless reports, equating technical weaknesses as just as relevant as a gap in a policy.

Phase 3 - The vast majority of government executives are clueless when it comes to IT. They know a little bit, like the name of an operating system (Linux - buzzword - yay!) but not much else. So, they are easily led astray. Most will allow a system to operate regardless of how bad it is, based on a horrible security review performed by incompetent certification agents, on a package made by the almost as clueless system owner and his staff.

After a system gets an authorization to operate, many staffs stop doing all security for 3 years, til the next C&A comes around.

It is not uncommon for a federal cabinet level agency to have 300+ systems, with 300+ system owners, with 300+ completely separate, unique and underfunded security implementations that have more holes than swiss cheese.

If you notice, what is missing from above is actually rigorous security analysis. Code is rarely audited. Configurations are rarely checked 100%. Policy is viewed as important as technical controls. Most testing is a wash. Penetration tests are vulnerability scans by nitwits.

And you wonder why the Chinese are plundering the US govt on a daily basis?

The clocks in orbit are either Rubidium or Cesium based. The US Primary Time Standard is a Cesium Fountain.

http://tf.nist.gov/cesium/fountain.htm

The GPS clocks are synchronized to the Master Clock.

http://tycho.usno.navy.mil/clocks.html

http://tycho.usno.navy.mil/mc_to.html

Ok, so maybe you won't find 311,000 vulnerabilities. I thought that was an obvious exaggeration, but you could have at least clicked the first 2 search results. For example:

Password stored in keyboard buffer - http://www.ivizsecurity.com/security-advisory-iviz-sr-0803.html
Cold Boot Attack - http://www.mydigitallife.info/2008/07/24/bitlocker-filevault-dm-crypt-and-truecrypt-encryption-key-crack-via-dram-cold-boot-attack-with-program-source-code-download/

If you also searched for truecrypt at http://www.nist.gov/ you would have found these four.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-3899
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1738
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-1589
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2006-2183

This is from wikipedia, for more information go to http://en.wikipedia.org/wiki/Truecrypt#Security_concerns

"TrueCrypt is vulnerable to various attacks. To prevent certain types of attack, the TrueCrypt website recommends users follow various security precautions.

Listed below are known security concerns pertaining to TrueCrypt and, where possible, some ways to avoid them

Plausible deniability
Identifying TrueCrypt volumes
Passwords stored in memory
The "Stoned" bootkit
Removal of source"

It's not that I hate TrueCrypt, I don't. I don't like it when people are pushing open source products for security reasons when it's the standards that the product uses which should be pushed. Since your response was to "prove" there are vulnerabilities, I did that. Now it's your turn to start pushing open standards and not a product because it happens to work for you and you like it.

Agreed?

Ok, so maybe you won't find 311,000 vulnerabilities. I thought that was an obvious exaggeration, but you could have at least clicked the first 2 search results. For example:

Password stored in keyboard buffer - http://www.ivizsecurity.com/security-advisory-iviz-sr-0803.html
Cold Boot Attack - http://www.mydigitallife.info/2008/07/24/bitlocker-filevault-dm-crypt-and-truecrypt-encryption-key-crack-via-dram-cold-boot-attack-with-program-source-code-download/

If you also searched for truecrypt at http://www.nist.gov/ you would have found these four.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-3899
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1738
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-1589
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2006-2183

This is from wikipedia, for more information go to http://en.wikipedia.org/wiki/Truecrypt#Security_concerns

"TrueCrypt is vulnerable to various attacks. To prevent certain types of attack, the TrueCrypt website recommends users follow various security precautions.

Listed below are known security concerns pertaining to TrueCrypt and, where possible, some ways to avoid them

Plausible deniability
Identifying TrueCrypt volumes
Passwords stored in memory
The "Stoned" bootkit
Removal of source"

It's not that I hate TrueCrypt, I don't. I don't like it when people are pushing open source products for security reasons when it's the standards that the product uses which should be pushed. Since your response was to "prove" there are vulnerabilities, I did that. Now it's your turn to start pushing open standards and not a product because it happens to work for you and you like it.

Agreed?

Ok, so maybe you won't find 311,000 vulnerabilities. I thought that was an obvious exaggeration, but you could have at least clicked the first 2 search results. For example:

Password stored in keyboard buffer - http://www.ivizsecurity.com/security-advisory-iviz-sr-0803.html
Cold Boot Attack - http://www.mydigitallife.info/2008/07/24/bitlocker-filevault-dm-crypt-and-truecrypt-encryption-key-crack-via-dram-cold-boot-attack-with-program-source-code-download/

If you also searched for truecrypt at http://www.nist.gov/ you would have found these four.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-3899
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1738
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-1589
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2006-2183

This is from wikipedia, for more information go to http://en.wikipedia.org/wiki/Truecrypt#Security_concerns

"TrueCrypt is vulnerable to various attacks. To prevent certain types of attack, the TrueCrypt website recommends users follow various security precautions.

Listed below are known security concerns pertaining to TrueCrypt and, where possible, some ways to avoid them

Plausible deniability
Identifying TrueCrypt volumes
Passwords stored in memory
The "Stoned" bootkit
Removal of source"

It's not that I hate TrueCrypt, I don't. I don't like it when people are pushing open source products for security reasons when it's the standards that the product uses which should be pushed. Since your response was to "prove" there are vulnerabilities, I did that. Now it's your turn to start pushing open standards and not a product because it happens to work for you and you like it.

Agreed?

Ok, so maybe you won't find 311,000 vulnerabilities. I thought that was an obvious exaggeration, but you could have at least clicked the first 2 search results. For example:

Password stored in keyboard buffer - http://www.ivizsecurity.com/security-advisory-iviz-sr-0803.html
Cold Boot Attack - http://www.mydigitallife.info/2008/07/24/bitlocker-filevault-dm-crypt-and-truecrypt-encryption-key-crack-via-dram-cold-boot-attack-with-program-source-code-download/

If you also searched for truecrypt at http://www.nist.gov/ you would have found these four.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-3899
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1738
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-1589
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2006-2183

This is from wikipedia, for more information go to http://en.wikipedia.org/wiki/Truecrypt#Security_concerns

"TrueCrypt is vulnerable to various attacks. To prevent certain types of attack, the TrueCrypt website recommends users follow various security precautions.

Listed below are known security concerns pertaining to TrueCrypt and, where possible, some ways to avoid them

Plausible deniability
Identifying TrueCrypt volumes
Passwords stored in memory
The "Stoned" bootkit
Removal of source"

It's not that I hate TrueCrypt, I don't. I don't like it when people are pushing open source products for security reasons when it's the standards that the product uses which should be pushed. Since your response was to "prove" there are vulnerabilities, I did that. Now it's your turn to start pushing open standards and not a product because it happens to work for you and you like it.

Agreed?

Ok, so maybe you won't find 311,000 vulnerabilities. I thought that was an obvious exaggeration, but you could have at least clicked the first 2 search results. For example:

Password stored in keyboard buffer - http://www.ivizsecurity.com/security-advisory-iviz-sr-0803.html
Cold Boot Attack - http://www.mydigitallife.info/2008/07/24/bitlocker-filevault-dm-crypt-and-truecrypt-encryption-key-crack-via-dram-cold-boot-attack-with-program-source-code-download/

If you also searched for truecrypt at http://www.nist.gov/ you would have found these four.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-3899
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1738
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-1589
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2006-2183

This is from wikipedia, for more information go to http://en.wikipedia.org/wiki/Truecrypt#Security_concerns

"TrueCrypt is vulnerable to various attacks. To prevent certain types of attack, the TrueCrypt website recommends users follow various security precautions.

Listed below are known security concerns pertaining to TrueCrypt and, where possible, some ways to avoid them

Plausible deniability
Identifying TrueCrypt volumes
Passwords stored in memory
The "Stoned" bootkit
Removal of source"

It's not that I hate TrueCrypt, I don't. I don't like it when people are pushing open source products for security reasons when it's the standards that the product uses which should be pushed. Since your response was to "prove" there are vulnerabilities, I did that. Now it's your turn to start pushing open standards and not a product because it happens to work for you and you like it.

Agreed?

If the fit ever takes anyone to make room for newer items, and you need to shift old software out of the way, think of donating it to the National Software Reference Library. We'll even pay the shipping. You'll be helping a unique resource.

ITYM "8 K".

SI units are capitalized when the name of the unit is derived from the name of a person.

source

I read the policy and consider it correct.

There are two ways to fix the abuse of the SI standard for base-2:

1. Correct the application to divide by 1,000 and keep on using SI prefixes.
2. Correct the application to keep on dividing by 1,024 but use the IEC prefixes.

So, use the IEC prefixes and you don't need to change much. Its just a little i.

Furthermore, this was approved in 1998. Don't you think you had enough time to adapt by now?
http://physics.nist.gov/cuu/Units/binary.html

I'm sure there are more distros and programs implementing this.

please post your java scimark score! we really need some scores for the N280, and amd's L110, thank you.

http://math.nist.gov/scimark2/run.html

I believe there should be a list of what is allowed and everything else is disallowed.

That's pretty much the way it is. They actually have a pretty secure MS ecosystem. Between DISA, NIST and USAF and Microsoft, they've come up with the Federal Desktop Core Configuration (FDCC) (which is an outgrowth of the USAF 'Standard Desktop Computer' (SDC)).

Various security settings, GPO's, etc. If you use a standard FDCC image, it is pretty well locked down, AND can be administered from anywhere. Having said that...'locked down' as much as XP or Vista can be. But the VAST majority of users do not need much more than Office and the base OS. No real need for 8 zillion extra little tools, which may or may not have their own vuln's.
But there is quite a lot on the approved list. Installed on a case by case eval. Wireshark or Firefox, for example. It is up to each department to further refine that list. For instance, the USAF (mostly) bans Firefox in favor of IE7.

Why the hell are they running MS OSes anyway?

Changing the US fed govt infrastructure from MS to 'something else', Linux for example, will take an extremely long time, and may well end up worse than it is now. Take the Munich example and multiply the problems by 500. For better or worse, an org of that size can't just switch.

Hey sg,

The thing is that a decentralised system isn't a bad thing at all. PKI was designed, from the start, to be usable as a non-centralised system (non-pyramid). Realistically speaking, using the same example as the one you offered, where a doctor needs to validate medical records provided by the patient to be truthful, you only need to verify the other doctor's credentials and a signed file.

Now we get back to the old "How do I trust another doctor's certificates?", well, we use a centralised service. Each doctor needs to enroll (Google cache of the same document) to get his certificates, and they are delivered by a central authority, possibly governmental (or whatever authority governs doctors in your country). It's not a very hard thing to do, and can be implemented for roughly a couple million dollars -- the whole system.

How many doctors are there in the US? A laughable amount if you compare how many certificates are issued for the DoD. Heck, you could even implement it to be fully PIV-C compatible, and get cross-certification from the US government, and would allow doctors' credentials to be easily validated during a crisis.

Heck, nobody even needs to own the PKI solution in the US. The government can do it for you, if you are a valid organisation, an excellent project provides certificate management for you. Outside the US it gets a bit more difficult, as interoperability is not quite as great as in the US, however PIV is starting to have quite a lot of traction in Europe as well (I can't remember off the top of my head if it's PIV-I or PIV-C that is being implemented with the UK police forces). A pretty good read (Google cache as it doesn't seem to be loading from here) about how data is provided on a PIV smartcard.

That being said, maybe the health care professionals ought to have raised their voice at the same time the engineers and scientists did (Google cache)?