- SCAP-On-Apple - lists.macosforge.org

[MacOSForge.org] Servers will be down for scheduled maintenance - TUE 11 MAR 2014 8AM-12PM PST
by Shawn Geddis 10 Mar '14

10 Mar '14

SmartCardServices & SCAP-On-Apple Participants, Scheduled maintenance on ALL Mac OS Forge Servers will be taking place on TUE 11 MAR 2014 8AM-12PM PST. It is scheduled to start at 8AM PST and the activity is expected to take about four hours or more resulting in shutdown until at least 12PM PST. All affected servers will be going through a change in IP address. DNS changes to the domain will be made and its propagation to the Public domains will take approximately 30 Mins to an hour. When maintenance begins, all MacOSForge systems are expected to stop functioning. We very much appreciate your participation and hope the scheduled downtime does not negatively impact your efforts. If you have any questions, comments or otherwise, please drop a line to the projects Admin account: SmartCardServices Admin scs-admin(a)macosforge.org SCAP Admin scap-admin(a)macosforge.org - Shawn _______________________________________________________________________ Shawn Geddis Enterprise Security Consulting Engineer, Apple (geddis(a)apple.com) SCAP-On-Apple Project/Dev Lead: (SCAP-On-Apple.MacOSForge.Org) SmartCardServices Project/Dev Lead: (SmartCardServices.MacOSForge.Org) _______________________________________________________________________

1 0

tickets 42-52, file should not have an extended ACL
by Peter Link 12 Aug '13

12 Aug '13

http://scap-on-apple.macosforge.org/trac/report/8 I wasn't looking at the tickets, only the Wiki page, so didn't realize there's been lots of progress made. Regarding tickets 42-52, I've seen something similar to identifying whether a program/application/executable/file has a particular setting in other OS testing. I presume these were identified by Shawn as files that shouldn't have an extended ACL configured for some reason. I am guessing the person who argued against requiring these tests is Jeffrey Blank, who stated there are thousands of files that could be tested with no real reason for testing them. OSX has the ability to verify and repair disk permissions using Disk Utility. This process goes through the entire disk, comparing file (and maybe ACL) permissions against a file containing the correct permissions. It includes non-Apple files so it gets updated when non-Apple applications are installed. Having all files properly configured is extremely important since it's an obvious way for malware to attack a system, therefore, I feel file settings are critical to a properly configured Mac. How it's done is up for discussion. 1. Do we create a CCE entry for every check Disk Utility performs when verifying file permissions? 2. Do we create a CCE entry for the Disk Utility file permissions verification process and leave it at that? How are people intending to use the information gathered by the ACL checks? Would we need a separate OVAL test for each ACL check listed in tickets 42-52 or could we have one CCE and one OVAL test that simply runs: diskutil verifyVolume MountPoint|DiskIdentifier|DeviceNode This will return lots of information while running (when using the terminal) but the expected result would be: The volume MacFusHD appears to be OK (had fun replacing my 2009 iMac's hard drive with an OWC SSD and larger HD, then creating a Fusion drive) Would this result, or one that says it needs repairing, be enough to satisfy everyone's desire to validate the proper settings for all OSX program files? Peter Link LLNL retired plink53(a)mac.com

1 0

ticket #53, iOS6
by Peter Link 12 Aug '13

12 Aug '13

http://scap-on-apple.macosforge.org/trac/ticket/53 This is the first iOS ticket I've seen. Are we working on OSX-only a combination of both or would it be better to create a separate iOS ticket list? Peter Link LLNL retired plink53(a)mac.com

1 0

Re: [SCAP-On-Apple] Mac OS X proposed pkginfo OVAL Test.
by Jacobsen, Jasen W. 24 Jul '13

24 Jul '13

At this year's Developer Days Workshop I presented a briefing to the OVAL developer community proposing an addition to OVAL that would allow querying of the OS X package receipt database as exposed by "pkgutil --pkg-info". During the briefing, I raised the issue – and it was confirmed by the Apple representatives attending – that while, the package receipt database provides historical data of what the Installer did, it does not necessarily represent current system state. E.g an application may have been installed at one time, but the user may have thrown it in the trash and deleted it; the receipt database would not reflect that change. The consensus from the attendees was that it would be preferable for OVAL to have a way to report accurate current system state rather than historical data that may not represent current system state. And until such an accurate reporting feature is available, it would be best to avoid adding a feature that exposes the package receipt database – thus perhaps leading OVAL content authors to write content that would return unreliable results. Based on that guidance, I look forward to working with the SCAP on Apple community to develop OVAL features to provide system auditing capabilities that comply with OS X best practices. Thanks to all who participated in the discussion leading up to the presentation. The insight you provided helped guide the OVAL developer community to make an informed decision. - Jasen.

1 0

Mac OS X proposed pkginfo OVAL Test.
by Jacobsen, Jasen W. 21 Jul '13

21 Jul '13

The Mac OS Installer program writes receipt files to a database after installing software. This receipt information includes version, install time, install volume, install location, and any groups the installed package may be a part of. This receipt information is precisely the type of data OVAL is frequently used to examine. This sort of information is already collected in other component schemas using the dpkginfo, rmpinfo, and other tests. The Apple provided way to get at this information is the "pkgutil" command line tool. It is proposed to create an OVAL test and supporting items based on the "pkgutil --pkg-info" command output. A detailed paper describing this test can be found at https://github.com/OVALProject/Sandbox/blob/master/resources/x-macos-pkginf…<https://github.com/jasenj1/Sandbox/blob/master/resources/x-macos-pkginfo/Ma…> The proposed schema can be viewed at https://github.com/OVALProject/Sandbox/blob/master/x-macos-pkginfo.xsd<https://github.com/jasenj1/Sandbox/blob/master/x-macos-pkginfo.xsd> The Linux rpminfo test is very similar to what is being proposed and provides a good model. http://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/l… The structure of the proposed test is as follows: pkginfo_object package_id – The ID of the package to examine (volume? - pkgutil allows a different volume to be specified. It's unclear if this would be needed or useful.) pkginfo_state & pkginfo_item package_id – The ID of the package examined version – The version of the package install_time – When the package was installed. Given in seconds since the UNIX epoch. volume – The volume the package is installed on. location – The path where the package was installed, if specified at time of install. group – The group(s) the package is a part of. Element repeats for multiple groups. (filepath?– file(s) associated with the package. See question below for discussion of this.) Questions: Exactly what portions of the information provided by --pkg-info are needed for OVAL? e.g. Volume, location, group, filepath? Is there a public API to get the information provided by pkgutil? Or is calling the command the only way to get it? The rpminfo test has a "filepaths" behavior that will collect all of the files associated with a package. pkgutil supports the same function using the "-- files" command. Should this be added to the pkginfo test?

6 15

Re: [SCAP-On-Apple] [SCAP-On-Apple-Dev] Mac OS X proposed pkginfo OVAL Test.
by Jacobsen, Jasen W. 16 Jul '13

16 Jul '13

"Perhaps a systemprofiler_test is what's really in order, that could accept an XPATH like the OVAL ind:xmlfilecontent_test…" That seems to be where the discussion is headed – that there should be a test (or tests) based on system_profiler. But that does not resolve the discussion of whether there should or shouldn't be a test to examine the package receipt database. - Jasen. From: David Solin <david(a)joval.org<mailto:david@joval.org>> Organization: jOVAL Date: Monday, July 15, 2013 5:35 PM To: "scap-on-apple-dev(a)lists.macosforge.org<mailto:scap-on-apple-dev@lists.macosforge.org>" <scap-on-apple-dev(a)lists.macosforge.org<mailto:scap-on-apple-dev@lists.macosforge.org>> Subject: Re: [SCAP-On-Apple-Dev] [SCAP-On-Apple] Mac OS X proposed pkginfo OVAL Test. The system profiler has been the go-to authority for inventory information on OSX for as long as I can remember. So long, in fact, that I'd forgotten about it! (I once used it as the data source for an OSX Mac inventory solution for a demo). Perhaps a systemprofiler_test is what's really in order, that could accept an XPATH like the OVAL ind:xmlfilecontent_test... Regards, --David Solin

1 0

Re: [SCAP-On-Apple] [SCAP-On-Apple-Dev] Mac OS X proposed pkginfo OVAL Test.
by Jacobsen, Jasen W. 16 Jul '13

16 Jul '13

What about non application things like libraries, printer drivers or browser plug-ins? And can you elaborate a little on "use a metadata query and launch services to locate the apps"? Perhaps there are other OS X capabilities that OVAL should make available to system auditors. - Jasen. From: Josh Wisenbaker <dubs(a)apple.com<mailto:dubs@apple.com>> Date: Friday, July 12, 2013 11:44 AM To: Shane Shaffer <shane.shaffer(a)g2-inc.com<mailto:shane.shaffer@g2-inc.com>> Cc: MITRE Employee <jasenj1(a)mitre.org<mailto:jasenj1@mitre.org>>, oval-developer-list OVAL Developer List/Closed Public Discussion <oval-developer-list(a)lists.mitre.org<mailto:oval-developer-list@lists.mitre.org>>, "scap-on-apple(a)lists.macosforge.org<mailto:scap-on-apple@lists.macosforge.org>" <scap-on-apple(a)lists.macosforge.org<mailto:scap-on-apple@lists.macosforge.org>>, "scap-on-apple-dev(a)lists.macosforge.org<mailto:scap-on-apple-dev@lists.macosforge.org>" <scap-on-apple-dev(a)lists.macosforge.org<mailto:scap-on-apple-dev@lists.macosforge.org>> Subject: Re: [SCAP-On-Apple-Dev] [SCAP-On-Apple] Mac OS X proposed pkginfo OVAL Test. As for finding installed applications I’ve always found the best option is to use a metadata query and launch services to locate the apps, and then simply read the Info.plist from the bundle to get the version. You could then compare this to the installer DB to find any missing software that was claiming to be installed.

4 8

[Reminder] Weekly Closing of Settings Review SCAP-on-Apple Posts
by Shawn Geddis 03 Jun '13

03 Jun '13

SCAP-On-Apple: Talk & Dev [Reminder] Weekly Closing of Settings Review SCAP-on-Apple Posts - on Jun 3, 2013 Review the tickets, comment in the tickets, openly question/discuss on the lists... RSS for ... Blog Page: http://scap-on-apple.macosforge.org/feeds/posts/scap-on-apple/ All Tickets: http://scap-on-apple.macosforge.org/trac/report/6 Will be posting tutorial content relating to Configuration Profiles for those new to OSX / iOS. _______________________________________________________________________ Shawn Geddis Enterprise Security Consulting Engineer, Apple SCAP-On-Apple Project/Dev Lead: Project Wiki [http://SCAP-On-Apple.MacOSForge.Org] Mailing Lists [http://scap-on-apple.macosforge.org/trac/wiki/MailingList] SCAP Contact [scap-cotact(a)macosforge.org] SCAP Admin [scap-admin(a)macosforge.org] _______________________________________________________________________

1 0

[Announce] Community-based Settings Curation for OSX & iOS
by Shawn Geddis 29 May '13

29 May '13

SCAP-On-Apple User and Dev Community, (cross-post to Fed-Talk Community) The day has final come to begin digging in your heels with your shoulder to the grindstone! Several have been working hard behind the scenes, for several months now, to establish a bulk of the initial settings for OSX and iOS for public review, discussion, modifications and ultimately for approval and posting to the data feeds provided from this project. We have had some time and resource constraints that have negatively impacted our ability to reach this point on our original target date. Now, your wait is over and we can all dig in our heels and move this effort forward in a joint effort to bring the best and brightest together in a concerted effort for Settings Curation. I wanted to give everyone a bit of structure and guidance on how we plan to proceed to maximize our time, talents and goals for this project. Flow of Settings Curation - Iterative Process Selection of the next BLOCK of settings [selection by SCAP Core Team] Generation of a Ticket for each setting [for Tracking & Reference purposes] Blog posting of next Settings Block [announce posting of next block] Daily Community Review & discussion [Community review/discussion via List] Weekly Closeout of Review [Tickets closed one week after creation] Post Curated Settings to Repository [Post updated data repositories & feeds] In addition to the users and developers in this community, this process will also have close involvement by individuals from NIST, NSA and SCAP Experts to ensure a solid review and submission process is accomplished. Timing You will notice that we are targeting a weekly closeout of settings. This will give us a 'rolling review' and ONE FULL WEEK for review/feedback/modifications of each setting. We do not anticipate any setting requiring more time than that for vetting, but if it does, we will place the settings ticket on hold for later followup. CCEs We plan to prefix the corresponding settings tickets with a designated CCE# which, among other things, will aid this community in long term tracking of activity and outcome for any given CCE / setting. Data Feeds The data feeds necessary for testing will also be pulled and hosted here as a 'developing authoritative data feed'. Once we have completed our curated We have several hundred settings right now and anticipate throughout this process that some may be significantly modified, dropped, added or approved as is. Guidance is that you jump right in on areas you are most knowledgable on and then progress to those you are unfamiliar or interested in learning more about with community discussion. Tool Vendors We encourage all tool vendors to participating and contribute validation feedback on all data tested from here against your own available tool sets. Right now this activity would be premature in the process, but keep this in mind for your organization's resource planning. We want to Thank You all in advance for waiting on us for so long and for your willingness to actively engage in the SCAP-On-Apple Project. If for any reason you have questions or comments, please do not hesitate to send them directly to this list for community feedback as well. Contact / Admin email addresses are also in the signature below. -Shawn _______________________________________________________________________ Shawn Geddis Enterprise Security Consulting Engineer, Apple [geddis(a)apple.com] SCAP-On-Apple Project/Dev Lead: Project Wiki [http://SCAP-On-Apple.MacOSForge.Org] Mailing Lists [http://scap-on-apple.macosforge.org/trac/wiki/MailingList] SCAP Contact [scap-cotact(a)macosforge.org] SCAP Admin [scap-admin(a)macosforge.org] _______________________________________________________________________

1 0

Re: [SCAP-On-Apple] [Fed-Talk] SCAP-On-Apple: I cannot find any automated SCAP content on the site.
by Haynes, Dan 29 Jan '13

29 Jan '13

As David mentioned, vulnerability content for OSX would be a great starting point for the community. Shawn, is there an authoritative feed or source of information that could be parsed and used to auto-generate vulnerability content for OSX? Thanks, Danny From: fed-talk-bounces+dhaynes=mitre.org(a)lists.apple.com [mailto:fed-talk-bounces+dhaynes=mitre.org@lists.apple.com] On Behalf Of David Solin Sent: Tuesday, January 29, 2013 1:59 PM To: fed-talk(a)lists.apple.com Subject: Re: [Fed-Talk] SCAP-On-Apple: I cannot find any automated SCAP content on the site. "Our" content is just an SCAP 1.2 datastream converted from the NSA's XCCDF 1.1 content... which is automated! The DISA content you reference below, Luis, appears to be 100% manual XCCDF; no automation at all. On 1/29/2013 12:20 PM, Luis Nunez wrote: Not sure if someone mention this on the tread but DISA just released a STIG for iOS 6 (XCCDF). It contains some 60 rules. I've not done a in-depth comparison but it looks very similar to the the jOVAL SCAP content for iOS5. With some additional updates I could see the iOS6 STIG having all the automation capabilities (OVAL). http://iase.disa.mil/stigs/net_perimeter/wireless/smartphone.html -ln On Jan 29, 2013, at 10:32 AM, John Oliver wrote: LANL (Los Alamos National Laboratory) is a big-time Mac user. From: David Solin <david(a)joval.org<blockedmailto:david@joval.org>> Organization: jOVAL Date: Tuesday, January 29, 2013 7:21 AM To: Apple Fed-Talk <fed-talk(a)lists.apple.com<blockedmailto:fed-talk@lists.apple.com>> Subject: Re: [Fed-Talk] SCAP-On-Apple: I cannot find any automated SCAP content on the site. 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<blockedhttp://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" <raymond.jacob(a)navy.mil<blockedmailto:raymond.jacob@navy.mil>> 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 (Fed-talk(a)lists.apple.com<blockedmailto:Fed-talk@lists.apple.com>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/fed-talk/link1%40llnl.gov<blockedhttps://lists.apple.com/mailman/options/fed-talk/link1%40llnl.gov> This email sent to link1(a)llnl.gov<blockedmailto:link1@llnl.gov> Peter Link Cyber Security Analyst Cyber Security Program Lawrence Livermore National Laboratory PO Box 808, L-315 Livermore, CA 94551-0808 link1(a)llnl.gov<blockedmailto:link1@llnl.gov> _______________________________________________ Do not post admin requests to the list. They will be ignored. Fed-talk mailing list (Fed-talk(a)lists.apple.com<blockedmailto:Fed-talk@lists.apple.com>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/fed-talk/david%40joval.org<blockedhttps://lists.apple.com/mailman/options/fed-talk/david%40joval.org> This email sent to david(a)joval.org<blockedmailto:david@joval.org> -- jOVAL.org<http://jOVAL.org>: SCAP Simplified. Learn More<blockedhttp://www.joval.org> | Features<blockedhttp://www.joval.org/features/> | Download<blockedhttp://www.joval.org/download/> _______________________________________________ Do not post admin requests to the list. They will be ignored. Fed-talk mailing list (Fed-talk(a)lists.apple.com<blockedmailto:Fed-talk@lists.apple.com>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/fed-talk/john.n.oliver.ctr%40navy.m…<blockedhttps://lists.apple.com/mailman/options/fed-talk/john.n.oliver.ctr%4…> This email sent to john.n.oliver.ctr(a)navy.mil<blockedmailto:john.n.oliver.ctr@navy.mil> _______________________________________________ Do not post admin requests to the list. They will be ignored. Fed-talk mailing list (Fed-talk(a)lists.apple.com<mailto:Fed-talk@lists.apple.com>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/fed-talk/lnunez%40c3isecurity.com This email sent to lnunez(a)c3isecurity.com<mailto:lnunez@c3isecurity.com> _______________________________________________ Do not post admin requests to the list. They will be ignored. Fed-talk mailing list (Fed-talk(a)lists.apple.com<mailto:Fed-talk@lists.apple.com>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/fed-talk/david%40joval.org This email sent to david(a)joval.org<mailto:david@joval.org> -- jOVAL.org: SCAP Simplified. Learn More<http://www.joval.org> | Features<http://www.joval.org/features/> | Download<http://www.joval.org/download/>

1 0