Slashdot Mirror

One may argue the technical merits of CAPP/EAL certifications, but serious competitors in the federal IT market simply can't afford not to make the large investments in time and money to get them. Anyone interested in the details can explore:

http://niap.nist.gov/cc-scheme/in_evaluation.html
http://niap.nist.gov/cc-scheme/vpl/vpl_type.html

One may argue the technical merits of CAPP/EAL certifications, but serious competitors in the federal IT market simply can't afford not to make the large investments in time and money to get them. Anyone interested in the details can explore:

http://niap.nist.gov/cc-scheme/in_evaluation.html
http://niap.nist.gov/cc-scheme/vpl/vpl_type.html

RedHat and SuSE got certification last year. I wouldn't count that very long time. You might want to check this: http://niap.nist.gov/cc-scheme/vpl/vpl_type.html#o peratingsystem

This is the short-form explanation. If you somehow decide to care about this more seriously, aside from seeking professional help I would recommend that you consult the Book of Armaments...er...the *real* CC site: http://csrc.nist.gov/cc/

Each of the areas that Common Criteria cares about has an extensive set of "things in this area about which we care" that is the source of the ADO_IGS.1 (&c) items above. For a software item such as an OS, think of those as "claims".

For any area, the EAL just shows the level to which a "claim" has been examined and therefore can be proven. EAL 1 is basically "I read your marketing puff piece, and it sounds really good!". At a different extreme, EAL 5 is pretty close to "I did everything I could to review your code and attack your system, and I still couldn't get in". Unsurprisingly, most software falls somewhere in between. Surprisingly (or not), some software (particularly OSs) might go at EAL 3 or 4 but will still have holes. Why, one might ask? (!)

Unfortunately, it's because CC actually expects (but does not assume) that software authors did their jobs thoroughly--including not injecting unintentional bugs. Any bug that does not match the stated intent of a chunk of code, and which doesn't get caught on a code review (which might or might not happen during CC eval, but if it does should only repeat processes in place at the software vendor) would look to most of us like a HOLY CRAP VULNERABILITY -- but the CC process doesn't directly account for it in evaluating and certifying software. Is that a flaw? Yes. At the same time, if one wants to go out and procure an OS that supports an essential set of features related to user authentication, CC is more likely to provide an OS that implements that set. It doesn't mean that a CC-evaluated OS is the most secure, but it has a specific set of functions that can be shown to work.

I know that probably sounds like a steaming pile to some folks...but for one set of evaluation criteria, the above means that CC evaluation is good and nothing else quite takes the place. In an ideal world, CC evaluation would be only one data point in a decision to procure a product, along with other measures of effectiveness that can more truly show fitness of particular software for a particular purpose.

See http://niap.nist.gov/cc-scheme/st/ST_VID4012.html

The Common Criteria (CC) is an international standard (ISO 15408) for computer security. Its purpose is to allow users to specify their security requirements, to allow developers to specify the security attributes of their products, and to allow evaluators to determine if products actually meet their claims.

The National Institute of Standards and Technology (NIST) and the National Security Agency (NSA) have established a program under the National Information Assurance Partnership (NIAP) to evaluate IT product conformance to international standards. The program, officially known as the NIAP Common Criteria Evaluation and Validation Scheme for IT Security (CCEVS) is a partnership between the public and private sectors. This program is being implemented to help consumers select commercial off-the-shelf information technology (IT) products that meet their security requirements and to help manufacturers of those products gain acceptance in the global marketplace.... NIAP is in the Information Technology Laboratory at the National Institute of Standards and Technology. NIST is an agency of the U.S. Commerce Department's Technology Administration. NSA is an agency of the U.S. Department of Defense.

So it's really an International standard regulated by [a] U.S. agenc[y][ies].

Yes, however the fact remains that it's very easy to teach a biological system to do a task. Examples in recent months are the brain cells flying, insects flying a sim, insects learning how to detect chemicals very, very quickly.

Computers flying aircraft is harder, much much harder in the real world so far.

With software, we don't always known what it's going to do, look at the math error that caused the Patriot error at Dharan in 1991, or the fact that they cost the United States alone around 60 billion dollars a year.

"Software bugs, or errors, are so prevalent and so detrimental that they cost the U.S. economy an estimated $59.5 billion annually."
http://www.nist.gov/public_affairs/releases/n02-10 .htm

Biological systems are going to be more robust and easier to "program" than software/hardware systems simply because all the beta testing has been carried out over hundreds of millions, if not a billion years of evolution. 25,000 neurons which teach themselves through feedback, or insects who can already fly are going to be easier, more robust and cheaper than software/hardware.

I concur. NIST Boulder, as an example that I am familiar with, is developing certain techniques that can be used for quantum computing. (http://tf.nist.gov/ion/index.htm)

But the reason why the Time and Frequency division at NIST cares is because these techniques may yield better clocks in the future. (In fact, many breakthroughs in fundamental theoretical/experimental physics are applicable to clocks.) Meantime, however, the project gets mainstream-media publicity for quantum computing implications, gets funding from NSA, QuIST/DARPA, etc.

I'm sure it's a windfall for the physicists to do fundamental research, though, so "Hoorah Quantum Computers!!! (and cut me that check...)"

At least one other group (http://qdev.boulder.nist.gov/) is working on research similar to that published on PhysicsWeb, specifically using Josephson junctions in creating quantum bits & logic. That group was just recently setting up an honest phase measurement system, though, so are probably a bit behind in the research mentioned.

The reason that group plays with Josephson junction devices (how they justify it under the NIST banner)? Voltage standards. The reason they tell other funding agencies? Quantum computing, communication, and good-old-Alice-and-Bob.

I concur. NIST Boulder, as an example that I am familiar with, is developing certain techniques that can be used for quantum computing. (http://tf.nist.gov/ion/index.htm)

But the reason why the Time and Frequency division at NIST cares is because these techniques may yield better clocks in the future. (In fact, many breakthroughs in fundamental theoretical/experimental physics are applicable to clocks.) Meantime, however, the project gets mainstream-media publicity for quantum computing implications, gets funding from NSA, QuIST/DARPA, etc.

I'm sure it's a windfall for the physicists to do fundamental research, though, so "Hoorah Quantum Computers!!! (and cut me that check...)"

At least one other group (http://qdev.boulder.nist.gov/) is working on research similar to that published on PhysicsWeb, specifically using Josephson junctions in creating quantum bits & logic. That group was just recently setting up an honest phase measurement system, though, so are probably a bit behind in the research mentioned.

The reason that group plays with Josephson junction devices (how they justify it under the NIST banner)? Voltage standards. The reason they tell other funding agencies? Quantum computing, communication, and good-old-Alice-and-Bob.

Another good comment made at the NIST conference was that there really is no theoretical proof for the existence of a one-way function. Hash functions are black magic that just "happens to work" at this point. Also, there's no reason why factoring large numbers has to be so hard? (does there exist an O(n) or O(1) solution to factor an arbitrarily large number?)

So I agree with you that algorithm agility will be the only way to keep ahead of the progress made by researchers (Xiaoyun Wang et al.), at least until some serious thought goes into AHS.

By the way, the full conference proceeding are available here.

You're half right, SHA-256, 384, 512 are part of FIPS 180-2. That is, they are approved for government use. FIPS 180-2 (PDF Warning!)

Brief Caveat: SHA-1 is still more algorithmically secure, as finding a hash is not feasible on desktop computers. SHA-256 and higher length are in the same vein of logic that provides this security, but like any new algorithm, there is an insufficient amount of study to verify this. This applies to Whirlpool as well, AES might be sufficiently secure, but Whirlpool != AES.

I find all players with memory sticks, memory cards and harddisks way too expensive. The good old portable 12cm CD players are much more affordable. They start at $30 including shipping (see for example pricewatch). CD-R's at a price of $11/100 disks incl. shipping are almost for free. I would also not like to constantly upload music onto the memory or harddisk every time I am in the mood for something else. But, over time I got a bit tired of the bulky disks. So I decided to go for 8cm instead of 12cm. The 8cm disks are handy, the player is not much larger, both fit into a pocket and they occupy almost no space on the desk. There are cute little wallets for the mini CD available, too. The only thing that bothers me a bit is the limited capacity of 8cm CD's. 200+ MB (units) is barely enough for two albums compressed as MP3's with variable bit rate (EAC+Lame). For a long, good concerto the capacity is sometimes only sufficient for one Audio-CD. So, what I really like to see is a tiny MP3-player for 8cm DVD's. Those little 8cm DVD's have a capacity of about 1.5 GB and their price beats any memory stick and harddisk. Unfortunately most regular (12cm) DVD players would not play MP3 files from an ISO 9660/UDF formatted hybrid, thus I expect this could be a problem for the little players, too. But, I think a little bit of good will and better firmware can make all the difference. If someone knows about such a portable 8cm DVD MP3-player, then please let us know. IMHO that would be a great alternative to all those hundred+ dollar gadgets. Anything is fine with me, except SONY. Otherwise I think that would be a great new product for the market and hope someone picks up the idea, wouldn't it?

IMHO, they should keep making the adjustments to keep time in sync with the sun. What, should we go back to the chaotic days when there were multiple reference meridians (Cádiz, Paris, etc.)?

Even so, the US Govt considers 256 bit AES to be good enough for "Top Secret" documents so I doubt it's crackable in 90 days.

Actually no, they recommend using AES 256 for govn't sensitive, but unclassified data. For anything classified, they are using classified military algorithms.

Here is another: http://nvd.nist.gov/nvd.cfm?cvename=CVE-2005-3474

Well, Jean-Marie *has* contributed a lot to the Java community. While this particular post may look trivial or not super important, the Javolution framework does have a lot of nice features and is RTSJ (real-time Java) compliant. He's also contributed a lot to JScience, which is another interesting framework for scientific calculations.

BTW, a lot of realtime Java has to do with deterministic behavior, and lazy initialization is non-deterministic. I don't think the main point here is to save a little bit of time by doing the load up front, but rather to get deterministic behavior from the system later on. For instance, let's say I have a class that normally take 20us for the constructor to run, but takes 15ms to load the class. If I'm expecting to be able to allocate a new instance of this class inside a method that has a maximum run time of 100us, then the system will fail if lazy initialization takes place. If that means I just missed a whole bunch of sensor readings, or that motor ran longer than it was supposed to, it could have some very bad consequences.

If you're interesting in learning about real time systems, or about real time Java in particular, I highly recommend the NIST's report on requirements for real time Java:

http://www.itl.nist.gov/div897/ctg/real-time/intro .html

Derek

I found the NIST WindowsXP Security guide,
http://csrc.nist.gov/itsec/guidance_WinXP.html

Is there a comparable server guide?

Actually, this has been coming for a very long time.

Do you have any idea what the MTBF of a television is, much less the length of time before you reach the far end of the bathtub?

It has not been a "very long time" when the majority of the equipment sold has a useful lifetime, absent government action, of decades. It has not been a "very long time" when external digital converters recently cost $300-400 (when I last looked in early 2004). It has not been a "very long time" when digital OTA tuners have just begun to become widely available in anything but the largest televisions (see the other reply to your post).

When you purchase a television, you generally expect it to work for decades. It's a measure of the insanity of the screw-the-consumer attitude folks that the switchover is going to be delayed from 2006 to 2009.

Two Factor Authenticationis not the only part of the problem. It does helps a lot for strong authentication of the client. Some other important parts of the problem are:

1. Mutual Authentication. Short term, need to have the FI display something unique which helps the user tell for sure they are connected to who they think they are connected to. Longer term, need changes to Firefox and IE6 (which for me means 95% of my customers) so that the PKI credentials for the FI are displayed.
2. Need to be able to ask the client if I can query their computers status, and make sure that they have a current patch level and decent AV and Spyware protection. So, need to ask Linux and Windows (or other products installed on Windows and Linux) to provide capabilities, because I do not want to download code. After all, not my business. Could request this function with a special HTTP header.
3. Mid term to long term, I love the idea of a second factor (USB attachment) which supports PKCS#11 / PKCS#15. This, along with #1, prevents MITM attack.
4. Everywhere in the world, except maybe theU.S., we are rapidly rolling out EMV and VIS. So, we are going to have Smartcards in everyone's wallet, that will be a key part of the 2FA problem. Just need a small portable USB device to support a USB interface to the card. So far, I am having trouble with this, need something small enough to hang on your keychain. Wait a year or so, someone will build it.

On the server side, need to make some changes as well.

1. Proper support for tiered authentication. So, you can access less dangerous functionality with less authentication
2. Base the entire thing on a decent RBAC approach, so I can administer and keep track of what is going on. Note, DSD gives me a decent way to model tiered authentication.
3. Need to build a proper authorization framework so that the requirements for both a proper authentication tier and even a signature (OTP, Digitial Signature) on specific transactions can be enforced.

The bottom line:

1. The stronger the authentication of the client, the better. As we move towards 2FA, lets be careful to not make any stupid biometric decisions. Biometrics should only be used to gain access to the hardware second factor, for instance via a thumbprint. Then, it the second factor gets stolen, we just revoke the token; we do not need to cut off your thumb!
2. Mutual authentication. Not only does the client need to prove who they are, the FI needs to prove who it is. Some cool stop-gate things with GIFs and stuff are possible, but in the middle and longer term, changes to the browsers (the two that dominate my customer base are Firefox and IE)
3. Assurance the PC is protected. If you will excuse me the vanity, I will riff on "Clarke&'s Third Law", name it "Cameron's Law&", and state that "Any sufficiently infested PC cannot be protected from allowing the customer to be scammed". Frankly, I was really hoping that the Fed would step up to that in its

Two Factor Authenticationis not the only part of the problem. It does helps a lot for strong authentication of the client. Some other important parts of the problem are:

1. Mutual Authentication. Short term, need to have the FI display something unique which helps the user tell for sure they are connected to who they think they are connected to. Longer term, need changes to Firefox and IE6 (which for me means 95% of my customers) so that the PKI credentials for the FI are displayed.
2. Need to be able to ask the client if I can query their computers status, and make sure that they have a current patch level and decent AV and Spyware protection. So, need to ask Linux and Windows (or other products installed on Windows and Linux) to provide capabilities, because I do not want to download code. After all, not my business. Could request this function with a special HTTP header.
3. Mid term to long term, I love the idea of a second factor (USB attachment) which supports PKCS#11 / PKCS#15. This, along with #1, prevents MITM attack.
4. Everywhere in the world, except maybe theU.S., we are rapidly rolling out EMV and VIS. So, we are going to have Smartcards in everyone's wallet, that will be a key part of the 2FA problem. Just need a small portable USB device to support a USB interface to the card. So far, I am having trouble with this, need something small enough to hang on your keychain. Wait a year or so, someone will build it.

On the server side, need to make some changes as well.

1. Proper support for tiered authentication. So, you can access less dangerous functionality with less authentication
2. Base the entire thing on a decent RBAC approach, so I can administer and keep track of what is going on. Note, DSD gives me a decent way to model tiered authentication.
3. Need to build a proper authorization framework so that the requirements for both a proper authentication tier and even a signature (OTP, Digitial Signature) on specific transactions can be enforced.

The bottom line:

1. The stronger the authentication of the client, the better. As we move towards 2FA, lets be careful to not make any stupid biometric decisions. Biometrics should only be used to gain access to the hardware second factor, for instance via a thumbprint. Then, it the second factor gets stolen, we just revoke the token; we do not need to cut off your thumb!
2. Mutual authentication. Not only does the client need to prove who they are, the FI needs to prove who it is. Some cool stop-gate things with GIFs and stuff are possible, but in the middle and longer term, changes to the browsers (the two that dominate my customer base are Firefox and IE)
3. Assurance the PC is protected. If you will excuse me the vanity, I will riff on "Clarke&'s Third Law", name it "Cameron's Law&", and state that "Any sufficiently infested PC cannot be protected from allowing the customer to be scammed". Frankly, I was really hoping that the Fed would step up to that in its

For more info see here: http://tf.nist.gov/general/misc.htm#Anchor-14550/

This concludes todays (off-topic) broadcast. Have a good evening.

The uncertainty of NIST-F1 is continually improving. In 2000 the uncertainty was about 1 x 10^-15, but as of the summer of 2005, the uncertainty has been reduced to about 5 x 10^-16, which means it would neither gain nor lose a second in more than 60 million years!

Although DSPAM is not an official participant at TREC, three configurations will be evaluated for comparison - with tum, toe, and teft training modes. Zdziarski reported some of the preliminary results in his interview, but complete and comparative results won't be available until TREC in November.

I guess we shouldn't have jettisoned WBS so quickly.

Perhaps you are unaware that NIST certifies encryption libraries so you don't have to believe marketing people. I would not use a product that can't show NIST certs.

Enumerating both good and bad programs is probably a good idea.

Exactly. Which is why the National Software Repository Library exists.

From the site:
The National Software Reference Library (NSRL) is designed to collect software from various sources and incorporate file profiles computed from this software into a Reference Data Set (RDS) of information. The RDS can be used by law enforcement, government, and industry organizations to review files on a computer by matching file profiles in the RDS. This will help alleviate much of the effort involved in determining which files are important as evidence on computers or file systems that have been seized as part of criminal investigations.

The RDS is a collection of digital signatures of known, traceable software applications. There are application hash values in the hash set which may be considered malicious, i.e. steganography tools and hacking scripts.

Using this, and some solid up-front admin work and strong procedures, a default deny on filesystems (especially server filesystems) is absolutely feasible and a good idea for strong security.

I'm a federal employee and information assurance is a huge part of my job. I don't understand why CERT needed another resource rather than tying things into NISTs shiny new National Vulnerability Database. Seems to me that one-stop shopping for both software vulnerabilities and malware alerts would be the thing to do.

Just in case anyone considers this a viable scenario here's a section from the AES factsheet (AES being just one of many contemporary strong encryption algorithms) about cracking AES:

"In the late 1990s, specialized "DES Cracker" machines were built that could recover a DES key after a few hours. In other words, by trying possible key values, the hardware could determine which key was used to encrypt a message.

Assuming that one could build a machine that could recover a DES key in a second (i.e., try 255 keys per second), then it would take that machine approximately 149 thousand-billion (149 trillion) years to crack a 128-bit AES key. To put that into perspective, the universe is believed to be less than 20 billion years old."

Now it's fair to say Google could process more than 255 keys/second but bear in mind doubling the processing power will only halve the attack time, and 149 trillion years needs an awful lot of halving to equal one minute.

The key sentence:
Jim Prendergast is executive director of Americans for Technology Leadership.

Americans for Technology Leadership Founding members
        * Association for Competitive Technology
        * Citizens Against Government Waste
        * Cityscape Filmworks
        * Clarity Consulting
        * CompTIA
        * CompUSA
        * Microsoft Corporation
        * 60Plus Association
        * Small Business Survival Committee
        * Staples, Inc.

http://www.cagw.org/site/News2?page=NewsArticle&id =8966&news_iv_ctrl=1037

itizens Against Government Waste (CAGW) today urged Congress to eliminate the National Institute of Standards and Technology's Advanced Technology Program (ATP), which funds private sector research and development

These are the other tech programs CAGW doesn't like.
http://www.atp.nist.gov/gems/listgems.htm

Who is Association for Competitive Technology?
http://www.actonline.org/aboutus.htm
While ACT members include some household names like eBay, Orbitz and Microsoft, our members are primarily small and mid-size companies. Smaller, entrepreneurial technology firms like Sax Software,

http://www.actonline.org/principles.htm
ACT and its members believe that the best way to achieve a healthy Tech Environment and a thriving technology industry is to apply free-market principles that promote innovation, investment and competition. ACT is committed to core free-market principles including:

        1. Consumers, not governments, should pick winners and losers in the marketplace.

        2. Small tech businesses thrive on innovation, not regulation and litigation.

        3. The law of regulation includes the corollary of unintended consequences.

  60 Plus has set ending the federal estate tax and saving Social Security for the young as its top priorities. Why should they be against this? It would save money in the long term.

        The Small Business & Entrepreneurship Council (SBE Council) works to influence legislation and policies that help to create a favorable and productive environment for small businesses and entrepreneurship. By educating policymakers, elected officials, the media and the public about the critical role that small businesses play in our economy--and how government actions can positively or negatively affect the small business community.

I don't know about you, but I'd want a refund from the SBE Council if they are supporting not going to an open document standard. A standard means that every small business could work and bid on any part of the project. Odds are most of the work would be done locally and not outsourced overseas. This is a great move for small business. (It is a bad move for those small businesses that store everything in their own little data format that only they know about. Which is exactly what this effort is trying to get rid of in the government realm.)

http://www.cryptography.com/cnews/hash.html
http://www.nsrl.nist.gov/collision.html

The NIST is having a two-day workshop in Gaitherburg, Maryland (USA) on October 31-Nov 1. Xiaoyun Wang will be giving a keynote speech, and there'll be plenty of technical material to go around. The workshop website is: www.csrc.nist.gov/pki/HashWorkshop/program.htm. I don't work for NIST or anything, but I thought this was interesting and they haven't really done a good job getting the word out about this conference.

Do keep in mind that the normal distribution and the Cauchy distribution appear to be similar except for the heavy tails of the Cauchy distribution. The mean and standard deviation have no meaning with the Cauchy distribution. Chaotic systems such as stock markets generally follow the Cauchy distribution... Perhaps nature does as well. See signature below. :^)

See instructions here and here

Also EAS was the result of a contest made by the _fine_folks_at_NIST_ (I owe a huge debt of gratitude to nist for their fine Open Source ATM network Simulator that I used in my thesis http://w3.antd.nist.gov/Hsntg/prd_atm-sim.html/).

The code that won was developed by a Belgian team, and therefore, not bounded by the restrictions, even if those restrictions were still enforced....

The press release from the _fine_folks_of_NIST_:
http://www.nist.gov/public_affairs/releases/g00-17 6.htm/

Also EAS was the result of a contest made by the _fine_folks_at_NIST_ (I owe a huge debt of gratitude to nist for their fine Open Source ATM network Simulator that I used in my thesis http://w3.antd.nist.gov/Hsntg/prd_atm-sim.html/).

The code that won was developed by a Belgian team, and therefore, not bounded by the restrictions, even if those restrictions were still enforced....

The press release from the _fine_folks_of_NIST_:
http://www.nist.gov/public_affairs/releases/g00-17 6.htm/

Lets review our SI units, shall we?

Kilo = 1,000
Mega = 1,000,000
Giga = 1,000,000,000

Lets review our data units, shall we?

Kibi = 2**10 = 1024
Mebi = 2**20 = 1,048,576
Gibi = 2**30 = 1,073,741,824

From the way it looks to me, hard drive manufacturers are actually the *most truthful* in their product descriptions. But I'm still not going to complain to DRAM manufacturers about getting an extra 24,870,912 bytes of RAM in my "512MB" stick.

http://physics.nist.gov/cuu/Units/binary.html
http://physics.nist.gov/cuu/Units/binary.html

dont confuse mega/mebi/kilo/kibi/giga/gibi/tera/tibi and so forth.....

get your facts right

http://physics.nist.gov/cuu/Units/binary.html
http://physics.nist.gov/cuu/Units/binary.html

dont confuse mega/mebi/kilo/kibi/giga/gibi/tera/tibi and so forth.....

get your facts right

Eh, the ordering of the SI prefixes is actually kibi-, mebi-, tebi-, etc. See here for more such nonsense. I, for one, find the new prefixes horribly unpronounceable, and expect them never to take hold in colloquial usage, save for the nerdiest of nerds. That said, it would be nice for them to be used in print, since the ambiguity is annoying at times.

• nsa.gov's own page on Security-Enhanced Linux.
• nist.gov's own page on OS X as a Common Criteria Certified OS in its default install.
• The complete list of certified OSes includes Windows 2K Professional, Server, and Advanced Server, but not XP, while Red Hat Enterprise 3 and SuSE Enterprise V8 are certified.

• nsa.gov's own page on Security-Enhanced Linux.
• nist.gov's own page on OS X as a Common Criteria Certified OS in its default install.
• The complete list of certified OSes includes Windows 2K Professional, Server, and Advanced Server, but not XP, while Red Hat Enterprise 3 and SuSE Enterprise V8 are certified.

We just had an article on this. There was a shootout by NIST. At least I think, /. search engine blows, hard. Either way, here a link to the tests. This is one that wasn't covered by the tests, so I guess its front page news.

a series of how-tos and standards docs
At the behest of the DOJ, NIST has been grinding out standards on how to forensically analyze a hard drive an other arcana for several years now.

NIST even provides tools: http://www.cftt.nist.gov/

a series of how-tos and standards docs
At the behest of the DOJ, NIST has been grinding out standards on how to forensically analyze a hard drive an other arcana for several years now.

NIST even provides tools: http://www.cftt.nist.gov/

As stated earlier, DoD requires their servers to be DITSCAP'd. The process costs at least $50K, takes about six months, and needs to be performed by an official who represents the requesting branch of the Government. I don't think that's what your looking for but it is a starting point. It's one thing to be DITSCAP certified, it's another the be DITSCAP compliant. check out http://www.nist.govand do a search for DITSCAP. You'll find all the relevant information there.

The first thing you need to know is how to write a SSAA (Site Security Accreditation and acceptance plan) Then it depends on which DoD agency who has the DAA (designated approving authority) as your company can not approve it, this will say if you need to use a DISA STIG, http://csrc.nist.gov/pcig/cig.html Or I it's the Marine Corps/Navy they will have there own checklist that is almost a direct copy of the STIG. USB drives are out along with floppy, and CD, while you may see a lot of people saying that you can have these on SABI (Secret and below infrastructure) its bad practice. You want only one point of entry for your system. Standard Pratice in places that actually follow the Regulations, is have a Security person (ISSO,SSO,AISSO) with a floppy and or CDrom and they are the point of entry for all incoming data. This data is then virus scanned, labeled, logged and put to a file share. As the first rule of Government security is you can not trust the users to do this. Then one of them works on a document at home, is infected but does not know with the new windows virus out there, slaps this floppy or cd into his system, thinks, "It's safe it came from my computer", and infects the entire network. You now have a security violation where you will have to do lots of paperwork, like, how did unauthorized data enter the network. Also you need to have an agreement that under repair or if you lease the computers. The Hard Drivers will not return with them.

Sigh!

The link you refer to points to material that is up to two decades old. The assurance levels you refer to (A, B, and C) are from the Orange Book, the seminal work of the Rainbow Series of security development manuals produced for the U.S. DoD.

The Rainbow Series was superceded in 1996 by the Common Criteria, an international agreement about security functional requirements, assurance requirements, and the processes needed to evaluate the security characteristics of IT products. Products that have met the requirements and undergone the process are listed in an Evaluated Products List. Among operating systems that have met the Common Criteria requirements are Mac OS X, Red Hat Enterprise Linux AS/WS 3, Solaris 9, SuSE Linux Enteprise Server V8, and Windows 2000 Server. All of these must be run on specific hardware configurations and with specific software configurations to retain their certified status in an operational environment. A recent project I was working on needed an HTML-based interface - imagine creating that on a Linux box that could not run X or even activate the frame buffer!

Secure systems are not just platforms that resist the latest script kiddie 'sploit. A system includes people, processes, hardware, software, development methodologies, and the operational environment. This is what makes a secure, assured SYSTEM, not just an expensive doorstop.

Links of (possible) interest:

Orange Book
http://csrc.ncsl.nist.gov/secpubs/rainbow/std001.t xt

Rainbow Series
http://csrc.nist.gov/secpubs/rainbow/

Common Criteria
http://www.commoncriteriaportal.org/

U.S. "Scheme"
http://niap.nist.gov/cc-scheme/

Evaluated Products List (EPL)
http://niap.nist.gov/cc-scheme/vpl/vpl_type.html#o peratingsystem

Sigh!

The link you refer to points to material that is up to two decades old. The assurance levels you refer to (A, B, and C) are from the Orange Book, the seminal work of the Rainbow Series of security development manuals produced for the U.S. DoD.

The Rainbow Series was superceded in 1996 by the Common Criteria, an international agreement about security functional requirements, assurance requirements, and the processes needed to evaluate the security characteristics of IT products. Products that have met the requirements and undergone the process are listed in an Evaluated Products List. Among operating systems that have met the Common Criteria requirements are Mac OS X, Red Hat Enterprise Linux AS/WS 3, Solaris 9, SuSE Linux Enteprise Server V8, and Windows 2000 Server. All of these must be run on specific hardware configurations and with specific software configurations to retain their certified status in an operational environment. A recent project I was working on needed an HTML-based interface - imagine creating that on a Linux box that could not run X or even activate the frame buffer!

Secure systems are not just platforms that resist the latest script kiddie 'sploit. A system includes people, processes, hardware, software, development methodologies, and the operational environment. This is what makes a secure, assured SYSTEM, not just an expensive doorstop.

Links of (possible) interest:

Orange Book
http://csrc.ncsl.nist.gov/secpubs/rainbow/std001.t xt

Rainbow Series
http://csrc.nist.gov/secpubs/rainbow/

Common Criteria
http://www.commoncriteriaportal.org/

U.S. "Scheme"
http://niap.nist.gov/cc-scheme/

Evaluated Products List (EPL)
http://niap.nist.gov/cc-scheme/vpl/vpl_type.html#o peratingsystem

Sigh!

The link you refer to points to material that is up to two decades old. The assurance levels you refer to (A, B, and C) are from the Orange Book, the seminal work of the Rainbow Series of security development manuals produced for the U.S. DoD.

The Rainbow Series was superceded in 1996 by the Common Criteria, an international agreement about security functional requirements, assurance requirements, and the processes needed to evaluate the security characteristics of IT products. Products that have met the requirements and undergone the process are listed in an Evaluated Products List. Among operating systems that have met the Common Criteria requirements are Mac OS X, Red Hat Enterprise Linux AS/WS 3, Solaris 9, SuSE Linux Enteprise Server V8, and Windows 2000 Server. All of these must be run on specific hardware configurations and with specific software configurations to retain their certified status in an operational environment. A recent project I was working on needed an HTML-based interface - imagine creating that on a Linux box that could not run X or even activate the frame buffer!

Secure systems are not just platforms that resist the latest script kiddie 'sploit. A system includes people, processes, hardware, software, development methodologies, and the operational environment. This is what makes a secure, assured SYSTEM, not just an expensive doorstop.

Links of (possible) interest:

Orange Book
http://csrc.ncsl.nist.gov/secpubs/rainbow/std001.t xt

Rainbow Series
http://csrc.nist.gov/secpubs/rainbow/

Common Criteria
http://www.commoncriteriaportal.org/

U.S. "Scheme"
http://niap.nist.gov/cc-scheme/

Evaluated Products List (EPL)
http://niap.nist.gov/cc-scheme/vpl/vpl_type.html#o peratingsystem

Sigh!

The link you refer to points to material that is up to two decades old. The assurance levels you refer to (A, B, and C) are from the Orange Book, the seminal work of the Rainbow Series of security development manuals produced for the U.S. DoD.

The Rainbow Series was superceded in 1996 by the Common Criteria, an international agreement about security functional requirements, assurance requirements, and the processes needed to evaluate the security characteristics of IT products. Products that have met the requirements and undergone the process are listed in an Evaluated Products List. Among operating systems that have met the Common Criteria requirements are Mac OS X, Red Hat Enterprise Linux AS/WS 3, Solaris 9, SuSE Linux Enteprise Server V8, and Windows 2000 Server. All of these must be run on specific hardware configurations and with specific software configurations to retain their certified status in an operational environment. A recent project I was working on needed an HTML-based interface - imagine creating that on a Linux box that could not run X or even activate the frame buffer!

Secure systems are not just platforms that resist the latest script kiddie 'sploit. A system includes people, processes, hardware, software, development methodologies, and the operational environment. This is what makes a secure, assured SYSTEM, not just an expensive doorstop.

Links of (possible) interest:

Orange Book
http://csrc.ncsl.nist.gov/secpubs/rainbow/std001.t xt

Rainbow Series
http://csrc.nist.gov/secpubs/rainbow/

Common Criteria
http://www.commoncriteriaportal.org/

U.S. "Scheme"
http://niap.nist.gov/cc-scheme/

Evaluated Products List (EPL)
http://niap.nist.gov/cc-scheme/vpl/vpl_type.html#o peratingsystem