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