TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
For companies like my employer, their products' validated
adherence to several FIPS standards is an absolute must.
[The following is general educational material that can
be read for interest, or totally ignored without penalty.]
In the data security field, FIPS is respected (and often
required) worldwide. But there are other standards
that have become important in the space. Some, like FIPS,
started off in just one country and then grew in acceptance,
so certain standards of (say) the German and Korean governments
are also used outside their countries. The EU Common Criteria EAL
is widely specified as a requirement, in every corner of the
corner-less spinning thing. It's another one we need to get
for most of our products.
One notable difference between FIPS standards and CC
standards is the time-frames. A FIPS validation might take
a year from first submission to posting of the validation cert
for your specific product and model on the NIST site. It's down
to a few months, if it's an incremental change to your product
and the evaluators are comfortable with an update to a certificate,
rather than a start-from-scratch evaluation.
The same product going for CC might take a year-and-a-half
to two years.
For that reason, our company tends to submit almost every
revision of every product (from my division, anyway) to FIPS,
but we are choosier about submitting to CC. Because it's so
lengthy and expensive, we might have two or three of our
product revisions go by between CC validations, so customers
who need it must remain with older product versions for longer
periods before the next available comes up. Customers who need
FIPS, but not CC, can rely on being able to update once per
year, if they wish, and still be FIPS-appropriate for THEIR auditors.
And, customers who like to be as up-to-date as possible,
and who don't have requirements for either standard validation
can update the day after each product release.
The above is not to say that CC is better than FIPS. CC is more
wide-ranging, and not as focused on the specifics that many
of our customers need. It's all a matter of where you live and
who you report to.
One commonality is the mutability. You don't go to the
standards organization itself for blessing. You go to certified
examiners in your country or region, who either bless your
product/service/process against the published standard,
or tell you where you fall short... testing labs and auditing services.
But the same product reviewed/tested by two different labs
against the same standard might yield two different test results.
Also, the individual standards are moving targets, and the industry
adherence to them can vary. For example, this-or-that new info,
like a particular kind of attack arising in the wild, or some new
research from a university might come along between official
revisions of a standard. Rather than wait for the standard to catch up,
the industry as a whole tightens up their interpretations of the
standard.
But that still leaves a spectrum of auditing/testing crews who
might be more-or-less conservative in their working
interpretation/application - that's how the same product revision
can sometimes pass with one crew and fail with another. What can
really bite is if your product meets the standard - and the current
interpretation of it - when you submit to a test laboratory's queue,
but the interpretation has shifted (or they hired some new engineers
or auditors) by the time your product gets to the top of the queue.
Experienced customers, looking at several competing vendors
in the field know that most-current FIPS or CC or Korean, etc.
validation is not the be-all of product selection, because competing
vendors are all on their own release schedules and are regularly
leap-frogging each other. The product evaluation and procurement
process normally takes more than half a year anyway, so by the time
a customer is getting ready to place orders, the vendor landscape
and the validation landscape is likely to have shifted from what it
was last year when the customer first put out their RFPs. That's why
a given customer will string along at least two potential vendors until
very late in the purchase process. Others simply have a policy to have
at least two vendors for every major system or component that they
buy. Then, they simply manage deployment within their own big
organizations until this-or-that product receives a needed agency
validation and can be put into service.
OK, more than you wanted to know. I'll stop now. But the tech
writer can fit into several niches within that grand scheme. You can
write the customer docs. You can be (or work for) the coordinator
who oversees the evaluation submissions process. You can work
for the testing labs and auditors. You can be the lucky soul who
writes and updates the standard itself at the government (or
other) agency that sponsors the standard.
-k
> -----Original Message-----
> From: techwr-l-bounces+kevin.mclauchlan=safenet-
> inc -dot- com -at- lists -dot- techwr-l -dot- com [mailto:techwr-l-
> bounces+kevin -dot- mclauchlan=safenet-inc -dot- com -at- lists -dot- techwr-l -dot- com] On
> Behalf Of Fred Ridder
> Sent: September-25-12 1:43 PM
> To: mattgras -at- comcast -dot- net; techwr-l -at- lists -dot- techwr-l -dot- com
> Subject: RE: Information security compliance
>
>
> Are you thinking of the FIPS (Federal Information Processing
> Standards) documents that are published by NIST (National Institute
> for Science and Technology)?
>
> The only other thing I can think of is the NSA (National Security
> Agency), which was involved with the DES standard and developed
> the SHA-1 and SHA-2 hash algorithms.
>
> -Fred Ridder
>
>
>
> > From: mattgras -at- comcast -dot- net
> > To: techwr-l -at- lists -dot- techwr-l -dot- com
> > Subject: Information security compliance
> > Date: Tue, 25 Sep 2012 09:27:22 -0700
> >
> > Anyone know the name / acronym of the organization that provides
> information
> > security compliance standards that companies try to comply with?
> >
> > It's on the tip of my tongue, but I can't quite catch it (something like
> > OSHA, but not...)
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create and publish documentation through multiple channels with Doc-To-Help. Choose your authoring formats and get any output you may need.
Try Doc-To-Help, now with MS SharePoint integration, free for 30-days.
