The reason that NIST puts out USGCB content for Windows and Linux is
that it's a funded project. I don't personally believe that it's
realistic to expect that anyone is ever going to go through the
trouble to develop, test and maintain SCAP content unless that's how
they're planning to feed their family -- meaning someone has to pay
for it.
There are commercial vendors like SecPod who create Mac content for
the purpose of selling it. I have no idea how much Mac content they
sell, but we support their efforts as part of our own (that is,
jOVAL's) business development program. If there are US government
agencies (like NASA? DoD? NSA? NOAA?) that depend on Macs, then it
might make sense for at least one of them to fund a position whose
purpose is to create automated security content around existing
best-practices like the manual STIGs. Heck, it could even be a
project for an intern! Since the government's not in the business
of selling this sort of thing, they might even decide to make it
available to the public.
On the other hand, there are also vendors who release vulnerability
signatures for their own products, in the form of SCAP content.
Novell (SUSE) and Cisco come to mind as examples. Shawn continues
to strongly hint (if not outright declare) that's just not going to
happen, but I think a lot of people are hoping that Apple might
decide to go down this route. If they did, it would no doubt be a
great starting-point for someone to put together an XCCDF benchmark.
We would be happy to work with anyone who wants to create SCAP
content for OSX or iOS, to insure that there is a working
open-source interpreter capable of running it. Anyone fitting this
description can send me an email to get started.
Regards,
--David Solin
On 1/29/2013 8:50 AM, Link, Peter R.
wrote:
Raymond,
The
whole idea of the SCAP-on-Apple project is to provide free SCAP
content for OSX systems. This means providing OVAL content as
well as XCCDF and CVE. I believe Apple already provides the CPE
product dictionary. Some vendors have provided varying levels of
XCCDF content while others have begin providing the mechanism to
deliver this content to Macs and iOS devices. I've seen
suggestions on the OVAL mail threads suggestions people work
with Apple on this. As Shawn continues to remind us (especially
me), Apple doesn't have the resources allocated to do all of
this, especially with the frequency of changes software goes
through and the instance amount of time it takes to get anything
through a committee or standards organization.
I've
also discussed the chicken and the egg aspects of SCAP and
security manuals. In my mind security manuals come first
followed by generation of SCAP content so that something like
the federally mandated USGCB baseline configuration can be
released. People will argue FDCC/USGCB never works but until you
try it and determine what doesn't work, it's all talk and no
action. People will argue they can configure systems better than
others but will not spend the time determining if one of their
settings actually puts a system at risk. Others will simple take
the direction of auditors who have no familiarity with OSX and
shut everything down without questioning whether there's even a
security vulnerability reason to do it.
For
those of you who actually have a large enough Mac installation
to justify more than a couple Mac technicians, I'd suggest
getting them involved in this process by working with others on
OVAL development, http://oval.mitre.org (check
for mailing lists), as the first step in creating standardized
system checks. Once on this list, remind the unix people that
although OSX is a unix OS, it has its own way of operating,
which isn't the same as linux and solaris and, therefore, needs
to be thought of as a totally separate OS instead of simply
trying to adapt unix tests to work with OSX. We've been there
with every Windows vendor trying to force altered Windows
applications onto Macs. Now unix application vendors are trying
to do the same thing.
This
is my final explanation and push for getting people involved in
this project. I'm not a programmer, I'm a facilitator; someone
who tries to get others to get together and work on a project
for the common good. That common good is the automated
configuration validation for continuous monitoring as required
by every federal system that follows NIST special publications.
Remember, CM-6, Configuration Settings, states that you have to
have a documented list of settings for your system. A few other
security controls tell you what some of those settings have to
be but the vast majority of them have to come from
somewhere/someone who has figured out what must be done to
properly secure a system. My goal for a long time has been to
get a USGCB baseline configuration for OSX but until we can find
programmers and IT personnel who are willing to work together to
put together the parts necessary for this baseline, we won't
have one.
I'm done and it's before my first cup of tea (6:49am).
On Jan 28, 2013, at 12:12 PM, "Jacob, Raymond A Jr. CIV
SPAWARSYSCEN-ATLANTIC, 58830" < email@hidden>
wrote:
Shawn:
/* SCAP Content means Mac OS/X ... */
I did not see any recent messages in the SCAP-On-Apple email
lists.
DoD(DISA STIG) as far as I know only has manual SCAP content
and as far as I can recall USCG referred one to the DISA
STIG.
Shawn:
1. I apologize in advance for not reading carefully enough
or
not understanding what I have read.
2. Can you ask your POC's at government agencies, if they
can make their automated SCAP content
available to the rest of the Government Community?
3. Can you mention 3rd parties that have automated SCAP
content for Mac OS/X?
Thank you,
raymond
_______________________________________________
Do not post admin requests to the list. They will be
ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Peter Link
Cyber Security Analyst
Cyber Security Program
Lawrence Livermore National Laboratory
PO Box 808, L-315
Livermore, CA 94551-0808
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|