Slashdot Mirror

I'm a different anonymous coward in the defense industry.

Instructions and checklists are available for common operating systems. Use the ones from DISA. Large companies often have their own methods for doing things that result in the same thing. At the end of the day, the customer (presumably DoD) must approve it. Note that different angencies have their own vagaries (DoE DoD, for example).

The guidelines provided here are often good for commercial security, also. In that environment, however, I would evaluate the requirements in a cost/benefit framework.

To confirm you're not a script, please type the word in this image: confuse [sweet irony]

I'd strongly recommend you read Defense Information Security Agency's guidelines for computing in a secure environment - you can find security technical implementation guides (STIGs) at https://iase.disa.mil/ but you need to conform to the STIG on both hardware and OS configuration.

You'll find other regulations for making machines that process classified material, but if you're looking for hardware specs it's pretty easy.

I don't belleve Windows XP has been certified by NIST but that doesn't mean you can't use it. If you're looking for a really high security Windows box the only Microsoft OS that's certified by NIST is Win2kSP3 with the Q326886 patch. You can get the patch by looking up the KB article number (Q326886) at http://support.microsoft.com./

Look here for more NIST information - http://niap.nist.gov/cc-scheme/vpl/vpl_type.html

Don't take my word as gospel, look at the regs - but here it is in a nutshell:

• Unless the box can be secured in a safe (like a laptop) it must have a removable hard drive and that hard drive must be stored in a safe when not in use.
• No wireless. Not any. Not 802.11, not Bluetooth. Do not pass go, go not collect $200. And it can't just be disabled, the hardware cannot have the capability.
• The machine must conform to both DISA STIGs and DoD CERT advisories.
• No Internet connections - you can connect a classified machine to a LAN provided the *entire* LAN is accredited and contained within the security vault. No outside network connections except to SIPRNet

To answer your other question - machines processing classified material can have removable drives - but removable media may never leave the physical security enclave unless it's properly accounted for.

Hope this helps -

It's scary to see how bad these answers are. I've been securing computers for the DoD and other angenies for 5 years. The short answer is that you don't need to do much. It depends on how many people need access, is it just for one project, how is the equipment secured when not in use, etc.

If you're doing CAD work, get a Dell Precision. If you buy the laptop version just stick the whole thing in a GSA secret approved safe when you're not using it. Otherwise with the desktop you'll need a removable hard drive. All the comments about turning off floppies and USB are stupid. You can have all of that stuff enabled...IF YOU NEED IT. When you fill in your security and IS plans you need to be able to justify what you've done.

As a starting point to securing the OS...wipe the drive, do a clean install NOT using those Dell restore disks (they put on a 32 MB FAT partition at the begining of the HD that is unsecure), format using NTFS, install drivers, apply SP2 plus all patches, install anti-virus, disable the NIC, turn off all unneeded services, install the DoD banner (you're gov't rep should give this to you). Document EVERYTHING. Anytime you even login...keep track of who, when, and that all security precautions were taken. Logging needs to be enabled on the OS.

Also, I hope you have a clearance, otherwise you'r enever going to use this computer again.

Here are some links that will get you started.

Defense Security Service (DSS)
http://www.dss.mil/infoas/index.htm

National Institute of Standards and Technology
http://csrc.nist.gov/

If you need more...email me (god help me for putting this on /. ...)
rjhedgehog@gmail.com

Good Luck!

Mod parent up!

All the guy is looking for is the official howto. DISA maintains them all.

Here it is again: http://iase.disa.mil/

All these posts and only one AC hits it :>

They have very detailed step-by-step guidelines for securing all kinds of boxes and OSs (including all of the administrative procedures).

Even other sites link in to their work:
http://csrc.nist.gov/pcig/cig.html

http://csrc.nist.gov/checklists/repository/

Without full access to what DoD, itself, would require, I would start from here and then fill in the gaps from SANS' reading room, and move on to studying security mailing list archives, and/or by asking specific questions in those public forums.

A lot of the guidelines are already published. You can find recommendations to software that can be installed to government encryption algorithms. Try this: http://iase.disa.mil/policy.html and http://www.nist.gov/

So, that captcha cuts out those people who have an internet connection AND have no phone AND are blind.

I'm assuming that a TTY connected to a braille wheel counts as a "phone" in your analysis, right?

I believe that if Windows does what you're asking it's documented here. [caution, pdf link]

Kernels are so big and bloated that there is almost %100 chance of there being some exploitable whole in them. If the "good hackers" discover it, it will be patched, if the "bad hackers" discover it, they will make rookits.

A lot of the code that is not tested and buggy is in the drivers, and I don't understand why do current operating systems still have drivers that are run in the kernel instead of in the user space. The machines are fast enough to switch contexts between the display, mouse, sound, disk and communication with the ports. The kernel should be very small and only implement the security policies and handle communications between devices. If the hacker manages to exploit a hole in the display driver, the driver will not crash the system. These are called secure microkernels or separation kernels. I think the present 4Ghz machines can hangle a %10 slowdown at the expense of say, %80, improved security. In 18 months, the speed will double anyway ;)

Check out this paper from NIST that talks about this. Also, more general info about it here

From actual physicists

Impedance (electric resistance) -> Ohm
Capacitance -> Farad
Inductance -> Henry.

http://csrc.nist.gov/CryptoToolkit/modes/proposedm odes/ProposedModesPage.html

Most of those MAC's can be used with an arbitrary block cipher (like, for example, genuine AES). A MAC with a known, fixed key degrades to a cryptographic hash, and doesn't require anything but genuine AES.

Dec. 23, 1975

Where have you been?

You mean this RSS feed?

If USA introduces DST for the whole year, you will actually generate a saving of about 365%, which means electricity will flow back to the powerplants ;)

http://tf.nist.gov/general/daylightsavingtime.html

Studies done by the U.S. Department of Transportation show that we trim the entire country's electricity usage by about one percent EACH DAY with Daylight Saving Time.

How is this going to save energy?
How about this?.

Here is a reason, you can decide on your own whether or not this is a 'good' reason.

Off topic: I love Battlestar Galactica. I think it is truly a great show. But, whoever invented the phrase "fracking" should be put in front of a firing line and shot.

Do the systems need to be synced to the outside world, or merely consistent with each other?

If the silly firewall people won't help you (you might remind them that you do in fact work for the same company...), you need to set up your own NTP server. Either a real one with a GPS receiver, or a pretend one that everybody can follow and have the same time, regardless of what that time actually is (see initial question).

The occasional phone call to the NIST's dialup time server might be useful too.

...laura

The article says that without leap-seconds the sun would start rising "a few seconds later each decade", but this would be compensated for by a leap-HOUR every 500-600 years. That equates to around 7 leap-seconds per YEAR though, which is much more that what is currently used. Even if the earth's rotation continues to slow, it's not slowing THAT much. In fact, it's been speeding up lately.

Plain ol' IPSec is not a cure-all in this situation.

In fact, if you want to believe NIST, most of the hardened encryption algorithms can all verge on introducing too much delay into the process. The solution is to introduce a priority scheduling component into encryption engines, but given the language of the report, I'm not sure that's widely done at the moment.

NIST has a nice technical report regarding all (or most) of the VoIP security approaches. It's quite lengthy, though, so use the ToC. http://csrc.nist.gov/publications/nistpubs/800-58/ SP800-58-final.pdf

And that contradicts the parent post how exactly? What makes you think s/he doesn't understand that???

Wow. Didn't think there was anyone on /. that didn't understand GB = 10^9 bytes and GiB = 2^30 bytes.
http://physics.nist.gov/cuu/Units/binary.html

The WWVB broadcast contains DST information. As long as every place in the US switches on the same day, and they don't change the switch time from 2AM, any "Atomic Clock" will automatically do the right thing. See the time code format information from NIST (although, annoyingly, it show two DST bits, but says the descriptions of them are "in the text", which is only available (as far as I can find) in a PDF of NIST Time and Frequency Services.

It probably explains the behavior of my clock, which goes to DST properly, but then goes back to standard time at 0000 UTC. It is probably resetting the "going to DST" bit at the new day, but not setting the "now in DST" bit. The next time it picks up a broadcast after 0000, the bit is set correctly and it fixes itself.

There's an interesting bit in one of the publications that says that devices should have a rule to change the DST setting if it hasn't received the signal for a while. I think it should probably NOT change the DST setting at all until it has received a signal, unless the user manually overrides.

The WWVB broadcast contains DST information. As long as every place in the US switches on the same day, and they don't change the switch time from 2AM, any "Atomic Clock" will automatically do the right thing. See the time code format information from NIST (although, annoyingly, it show two DST bits, but says the descriptions of them are "in the text", which is only available (as far as I can find) in a PDF of NIST Time and Frequency Services.

It probably explains the behavior of my clock, which goes to DST properly, but then goes back to standard time at 0000 UTC. It is probably resetting the "going to DST" bit at the new day, but not setting the "now in DST" bit. The next time it picks up a broadcast after 0000, the bit is set correctly and it fixes itself.

There's an interesting bit in one of the publications that says that devices should have a rule to change the DST setting if it hasn't received the signal for a while. I think it should probably NOT change the DST setting at all until it has received a signal, unless the user manually overrides.

Sorry -- that's just not right.

The WWVB time code does have a DST flag that indicates whether DST is in effect. That is true of every radio time-code broadcast I know about (e.g. the Rugby clock in England, MSF).

http://tf.nist.gov/stations/wwvbtimecode.htm

The DST setting on the clocks I have allows me to decide whether I want to display the time in DST or not.

The folks who designed WWVB are not idiots -- they actually thought ahead when the protocol was designed. Don't forget that DST has been used, canceled, used, doubled, and used again. They knew the rules were likely to change, and the original target devices were electromechanical -- no chance for any fancy stuff.

Check out the whole story -- It's good stuff.
http://tf.nist.gov/stations/radioclocks.htm

Sorry -- that's just not right.

The WWVB time code does have a DST flag that indicates whether DST is in effect. That is true of every radio time-code broadcast I know about (e.g. the Rugby clock in England, MSF).

http://tf.nist.gov/stations/wwvbtimecode.htm

The DST setting on the clocks I have allows me to decide whether I want to display the time in DST or not.

The folks who designed WWVB are not idiots -- they actually thought ahead when the protocol was designed. Don't forget that DST has been used, canceled, used, doubled, and used again. They knew the rules were likely to change, and the original target devices were electromechanical -- no chance for any fancy stuff.

Check out the whole story -- It's good stuff.
http://tf.nist.gov/stations/radioclocks.htm

Relax -- your investment in atomic clocks (really radio-controlled) is safe :) They get DST from the master clock already.

All of the radio-controlled or "atomic" clocks work on the same idea -- they receive a time signal from a low-frequency transmitter (60kHz in the US). The device will typically set an internal quartz clock from the received time code. The time reference signal is strongest at night, so it's typical for these clocks to set themselves at 2 or 3 am (local time). Some newer designs will set whenever the signal strength is high enough for a good read. This redundancy makes for a very reliable device.

The time code contains, among other things, a flag indicating whether DST is in effect. So -- when (if?) this change to the DST rules goes into effect, the folks who run the transmitter will change the flag at the proper moment, and the next time your clock reads the signal, et viola! it reads DST.

The radio station broadcasting the time code in the US is WWVB, and it is managed by NIST. The WWBV system is really an elegant design, involving a wonderful mixture of old and new technology. Check it out:

http://tf.nist.gov/stations/wwvb.htm

By the way, there are 4 other time zones east of US Eastern. The Atlantic time zone, for example applies in Nova Scotia. There are also similar time reference broadcasts in the EU, Russia, and Australia. There might also be one in China - but I've never needed to look that one up. I'm sure that will change one day soon.

No, your watch will be just fine. The DST/non-DST status is encoded in the WWVB data stream. See the NIST web site for details.

How about those "Atomic Clocks" sold at Radio Shack and Wal-mart?

If the one sold at Radio Shack is this Atomic Digital Travel Clock, then it receives a signal from WWVB, and their digital signal includes a daylight savings time indication, so assuming they do the right thing the "atomic clock" will Just Work.

Really, people, this is probably a lot less complicated than you might think. Many UN*Xes can just deal with it with zoneinfo file updates, and several people have indicated that it's a registry change in Windows. Perhaps some applications have their own time zone rule files, and perhaps OS/360^H^H^H^H^H^HMVS and z/OS aren't as easy to fix, but a lot of machines and applications will require only a small file/registry tweak.

How about those "Atomic Clocks" sold at Radio Shack and Wal-mart?

If the one sold at Radio Shack is this Atomic Digital Travel Clock, then it receives a signal from WWVB, and their digital signal includes a daylight savings time indication, so assuming they do the right thing the "atomic clock" will Just Work.

Really, people, this is probably a lot less complicated than you might think. Many UN*Xes can just deal with it with zoneinfo file updates, and several people have indicated that it's a registry change in Windows. Perhaps some applications have their own time zone rule files, and perhaps OS/360^H^H^H^H^H^HMVS and z/OS aren't as easy to fix, but a lot of machines and applications will require only a small file/registry tweak.

You sure? You might have something different, but every wall clock I've ever seen that does auto-daylight-time switching is a NIST shortwave receiver clock. You know, like this.

Daylight time switchover is coded in the WWVB signal. Everything will work perfectly, just like it was designed. Don't worry, be happy.

-Jay-

Signature or behavior based IPS systems are pretty useless against new code based attacks. It is better to harden the systems the code is running on. Implement the NIAP configuration guides http://niap.nist.gov/config_guide.html and use a host based solution like Securecore or Solidcore. Sana Entercept is also useful for an added layer of protection.

So are you saying that "pipeline data chunks" are the wrong way to think about most of our data and "objects" are?

The thing is that "pipeline data chunks" are a great UNIX invention. The thing that's wrong about them is that they need to be able to accomodate for metadata. Plain text just isn't that good, maybe.
There are deep reasons why CLI tasks aren't going away. It's called the algebra of programming languages and the hard theoretical fact that it allows infinite constructions. You can think of Unix streams as generators and as having the same compositionality as higher-order functions in languages such as Haskell. This formulation isn't mine, BTW, it's written in Shriram Krishnamurthi's book
Anything GUI-oriented to replace that would have to first establish some metadata on widget operations. The visual equivalent of Blissymbolics parsing and Expect. Still, you have a written language, because how would you transmit instruction for GUI operations "by wire"?. Written language is a major acquisition of civilization.
So anyone who is readily willing to dismiss Unixspeak/CLI hasn't really put much thought into it. Voice recognition is needed so that we can use our mouths for Unixspeak. Not that would be a cool open-source project. (I've basically repeated myself, but I wanted to throw in a few pointers).

It's not an order of magnitude, but it appears that among their many other interesting properties, carbon nanotubes can be made to hold up to 8% hydrogen by weight.

Nist News

Speaking as a customer service rep at a electrical utility, I think it would be one of my more NORMAL calls.
Typically speaking though, meters do not 'speed up.' With age, they slow down which does not work in the utility's favor, which is why they usually have a periodic meter replacement program, ie every 5 years.
I haven't ever sent out a service order on a meter that's ever tested too fast.
Many utility companies (like the one I work for) have automated metering, with meters transmitting at 917mhz back to a poletop box every 5 minutes for a second or so. (Like a cordless phone). What that means is that a lot of companies now have on their website a means for you to view your usage every day, so you can go online the next day after running your hot tub for a few hours and see how much extra you used in number and graph form.
But back to accuracy, typically, on a service order when a field rep goes out to test a meter, they will find the cause of the increased usage... like a new hot tub that was just installed :)
Meters all have to be tested to NIST standards... (from here: http://www.nist.gov/public_affairs/nhouse/watt.htm "NIST and Your Electricity Bill") No one needs reminding about those meters with little turning wheels that the power company uses for determining your monthly electricity bills. It may be of some solace to know there is a third party out there who is helping to make sure those watt-hour meters, as they are known, accurately record the amount of power you are using. That way you don't pay for more electricity than you actually use, and, in all fairness, the power company doesn't end up giving away its products for free.
This two-way assurance rests upon a short chain of calibrations anchored at the National Institute of Standards and Technology (NIST) where the ultimate power meter lives. The accuracy of every watt-hour meter in the country ultimately is traceable to the Electricity Division of NIST's Electronics and Electrical Engineering Laboratory. Most watt-hour meters are electromechanical devices in which a tiny portion of the electrical power going through it is converted into the mechanical clock-like motions that move the meter's dials. Just as clocks can be fast or slow, so too can watt-hour meters be off. That is why state public utility commissions (PUCs) own and maintain standard watt-hour meters with which they can certify the accuracy of mass-manufactured meters. Meters pass when they produce the same power reading as the standard meter when the same amount of current passes through them.
NIST provides the ultimate basis for these measurements because the standard meters of the PUCs go through periodic calibrations at NIST in which the amount of electricity going through a meter can be more accurately and confidently measured than anywhere else in the country. Once the standard watt-hour meters pass muster at NIST, they can serve as genuine gatekeepers for the much larger population of residential and business watt-hour meters.

Arrrrhhh! No.

0h 0m 0s = Midnight
12h 0m 0s = Noon.

These is no such time as 12:00:00am (or 12:00:00pm).

See NIST for the gory details.

The quicksort algorithm, however, is not terribly slow. (except in pathological cases) That's probably what's throwing off some of the other posters, they may be thinking qsort == quicksort. It's just one implementation of it.

In terms of algorithms, I've found merge sort to actually be significantly faster than quicksort in the presense of large data sets and caches due to the better locality, but it has complications for general-purpose sorting. IIRC, STL typically uses something similar to introspective sort.

The quicksort algorithm, however, is not terribly slow. (except in pathological cases) That's probably what's throwing off some of the other posters, they may be thinking qsort == quicksort. It's just one implementation of it.

In terms of algorithms, I've found merge sort to actually be significantly faster than quicksort in the presense of large data sets and caches due to the better locality, but it has complications for general-purpose sorting. IIRC, STL typically uses something similar to introspective sort.

The quicksort algorithm, however, is not terribly slow. (except in pathological cases) That's probably what's throwing off some of the other posters, they may be thinking qsort == quicksort. It's just one implementation of it.

In terms of algorithms, I've found merge sort to actually be significantly faster than quicksort in the presense of large data sets and caches due to the better locality, but it has complications for general-purpose sorting. IIRC, STL typically uses something similar to introspective sort.

What's wrong with the example that comes with Expect? It's probably already on your machine.

Unfortunately this is also a reminder of the risks we'll have to take if we ever get serious about colonizing space..

This is from a page linked from the article in the story about shear thinning..

http://science.nasa.gov/headlines/y2002/07jun_elas tic_fluids.htm

Researchers hope that a space-experiment called CVX-2 (short for "Critical Viscosity of Xenon-2") will soon provide new data about the basic physics of such fluids. Berg is the principal investigator for the experiment, which is slated to fly this summer onboard space shuttle Columbia (STS-107).

Experiments with simple chemicals rather than ZBLAN and other actually useful substances is probably critical for getting data that physicists can actually work with to try to understand shear thinning in general... And this CVX-2 experiment was conducted on Columbia's last mission.

Apparently they relayed most of the results of the CVX-2 experiment back to earth while still in orbit, according to this page. ..Just something to remember one day when we all have ultra cheap single-transmission fiberoptic lines right to every home.

The Aquaint program has been running for a few years now and before that there has been a question answering track held at the Text Retrievel Conferences where systems have to return exact answers to questions. In more recent years questions have also been list or definition based.

For those who are interested you can get info about the competing systems (academic papers some of which will contain links to demos of the systems) at the TREC website: http://trec.nist.gov/

The first evaluation to include question answering was TREC 8 so have a look there first as there is a nice overview paper discussing the task.

No worry. There are a few hash functions (PDF document) which have not been broken yet.

I like Tiger myself.

From the article: "The first atomic clock ... was born at the UK's National Physical Laboratory."

Well, the first -cesium- atomic clock was made at NPL, UK, which was certainly a major advance. But the FIRST ATOMIC CLOCK was built at the National Bureau of Standards (NBS) which is now known as NIST, in the US. So I disagree with the BBC's presentation of the situation.

Check out http://physics.nist.gov/GenInt/Time/ for more info and history than what was linked in the original post on this topic.

According to the article, it doesn't appear there were any previous celebrations ... and in the BBC piece it doesn't say if the clock got to do anything for turning 50. I climbed a mountain on my 40th birthday - someone ought to throw a party for the poor old clock! ;-)

It seems that more and more of everything is sync'd with this. My clock radio at home auto-updates, clock on the wall, the cellphones, my Linux and Mac PC's and cable box.

Only thing left are the clocks with a single AA battery on the wall, and at some point they are going to use the pervasive WWVB time signal that is broadcast from Colorado and operated by the National Institute of Standards and Technology

This technology has really come a long way and is deeply embedded within our lives. Especially if you consider that before the atomic clock, time varied considerably between different locales.

Technically, 25 million megabytes equals exactly 25 terabytes. The SI prefixes specify that mega means million, aka 10^6, and tera means trillion, aka 10^12.

The proper binary prefixes you should be using are mebi and tebi, meaning 2^20 and 2^40 respectively.

(I can't believe that /. won't let me use the <SUP> tag.)

Technically, 25 million megabytes equals exactly 25 terabytes. The SI prefixes specify that mega means million, aka 10^6, and tera means trillion, aka 10^12.

The proper binary prefixes you should be using are mebi and tebi, meaning 2^20 and 2^40 respectively.

(I can't believe that /. won't let me use the <SUP> tag.)

I use SI units - tebibytes.

Not to be too pedantic, but Newtons are a unit of force, Joules are units of energy. It may be that you want a unit of power, which is the Watt. See this handy chart.