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

Mac's Audit Data (slightly OT)
by Todd Heberlein 23 Jul '13

23 Jul '13

During the discussion started last week on trying to find out what programs, libraries, plug-ins, etc. were installed on a system to determine if a system is vulnerable, someone asked about using audit data (I think to validate the accuracy of data collected about programs). Virtually everywhere I go, no one seems to know that they can do with audit data, which isn't surprising since there aren't exactly a lot of books or training courses on audit data as there are for network monitoring. I put together this 7:38 min video on some of the information Apple's BSM audit data can provide. Should you be leveraging Apple's BSM audit system? http://www.netsq.com/Podcasts/Data/2013/AuditIntro/ If scap-on-apple will include audit system configuration, at some point we should have a discussion about what types of questions you want to ask of that data. Todd

2 1

Re: [SCAP-On-Apple-Dev] Configuration Profiles vs Plist file diddling
by Josh Wisenbaker 04 Jun '13

04 Jun '13

Hi Shane, I fully agree that having a master connection to see all of the composited defaults would be great, but we aren't there quite yet. It is fairly easy to work around from a scripting standpoint though and I'll investigate the programatic side of it a bit. The profiles command makes it pretty simple to interrogate the system for configuration profile data. Keep in mind that profiles can contain preference settings or configuration data. Things like loginwindow settings will show up in the ManagedPreferences folder, but configuration data like 802.1X or certificates will not. A simple 'sudo profiles -Pv' will show you if profiles are installed and what the non-secure parts of their payloads are. You can even more simply test to see if profiles are installed at all with 'profiles -H'. If that test returns false then we can proceed to the next step. (Currently we don't offer any public APIs to work with the ConfigurationProfiles.framework as it's private.) Settings that are preferences from mcx or profiles will show up in the master composited plist file at /Library/ManagedPreferences/<username>/complete.plist. You can simply read this in and see everything that's composited regardless of policy source. If the file doesn't exist, then there aren't any ManagedPreferences to look for. After that you can drop down to looking in defaults and plist files as we've done in the past. Is this a great or simple solution? No, not really. It is the best viable one we have to work with currently. We've got some pretty decent developer documents on the preferences system in general, NSUserDefaults, and CFPreferenceSettings. Josh -- Josh Wisenbaker Consulting Engineer - Apple U.S. Commercial and Governmental Sales dubs(a)apple.com On Jun 4, 2013, at 11:01 AM, Shane Shaffer <shane.shaffer(a)g2-inc.com> wrote: > While working with configuration profiles is likely the preferred configuration mechanism moving forward (if one hasn't already invested in another mechanism), the larger problem remains that there are multiple mechanisms for configuring settings such as these, with unclear relationships between those mechanisms and unclear behaviors within some mechanisms. If only configuration profiles were used it seems to be a relatively simple problem, but that's not realistic. We're dealing with systems that might have a profile configured this way, might be managed via Profile Manager, might have multiple conflicting .plist files across the multitude of locations in the preferences hierarchy (all the by host, by user, system wide, managed vs. local, etc. variants), and so on. Any configuration method specific assessment mechanism is ultimately of little value as long as multiple methods of configuration can be used. > > I've previously gone down the road of attempting to understand the hierarchy of .plist files and locations, but eventually realized that the effective precedence hierarchy differs from setting to setting (not all settings that may be configured in a plist file in one location are honored if set by that same plist file in another location, and other differences), and may be dependent on the state of the session lifecycle (i.e., one precedence hierarchy is used at login that makes a managed preference override a user level preference, but if the user can change the setting during that session it may override the managed preference for the duration of that session). Dealing with just plist files proved to be an impractical assessment problem due to the inconsistent behaviors and lack of documentation making it a frustrating trial and error effort. > > What we really need is a definitive way to determine the effective configuration of a setting regardless of configuration methods used. Sort of an extended MCXCompositor behavior I suppose. A capability that does this would be great for assessment, but to ensure proper remediation we also need documentation of how all these configuration methods interact so we can choose the most appropriate method and/or get the desired result regardless of method chosen. > > Shane Shaffer > G2, Inc. > shane.shaffer(a)g2-inc.com

1 0

Re: [SCAP-On-Apple-Dev] Configuration Profiles vs Plist file diddling
by Haynes, Dan 04 Jun '13

04 Jun '13

Thanks for getting this discussion started Josh and Prabhu! As Prahbu mentioned, we have the existing macos-def:plist510_test and the ind-def:xmlfilecontent_test that can support the assessment of plist files (including configuration profiles). There is also an experimental plist511_test in the OVAL Language Sandbox (https://github.com/OVALProject/Sandbox/blob/master/x-macos-plist-xpath.xsd) which utilizes xpath to reference the preference key of interest. To help show how these three tests can be used, I have attached sample definitions that check for CCE-28300-2 idle_time_for_screen_saver. Hope this helps! Thanks, Danny From: scap-on-apple-dev-bounces(a)lists.macosforge.org [mailto:scap-on-apple-dev-bounces@lists.macosforge.org] On Behalf Of Prabhu S Angadi Sent: Friday, May 31, 2013 3:38 AM To: scap-on-apple-dev(a)lists.macosforge.org Subject: Re: [SCAP-On-Apple-Dev] Configuration Profiles vs Plist file diddling Hi All, Yes! I completely agree with Josh, on the usage configuration profiles. Being the XML formatted content of these files can be easily parsed to fetch the composed policies values, to develop the SCAP OVALl definitions, using available '< xmlfilecontent_test >' or '< plist510_test >' probes for better assessment. And also, as these files can be easily deployed with customized values as per user's choice. Either by * By physically connecting the device * In an email message * On a webpage * Using over-the air configuration as described in this document so I think it will be of great use in remediation part as well. _______________________________________________________________________________________ In supportive to Josh, I have attached few Profile files, that were developed to address the Apple iOS Hardening Checklists by The University Of Texas at Austin. FMI : https://wikis.utexas.edu/display/ISO/Apple+iOS+Hardening+Checklist https://wikis.utexas.edu/display/ISO/iOS+Configuration+Profiles -- Thanks !! Prabhu S A http://www.scaprepo.com On 05/31/2013 02:50 AM, Josh Wisenbaker wrote: Hi all, I think that from an audit and remediation standpoint things can be greatly simplified by using Configuration Profiles. You can easily get a XML formatted list of the composited policies that are on the Mac and you can easily apply settings by installing a profile. Using the policy mechanisms in OS X is highly recommended over messing with files. As an example here is a profile I made that implements all of the settings for the initial loginwindow tickets that are in the tracker. This profile allows for removal without authentication so it's easy to test with. Thoughts? Josh -- Josh Wisenbaker Consulting Engineer - Apple U.S. Commercial and Governmental Sales dubs(a)apple.com<mailto:dubs@apple.com> _______________________________________________ SCAP-On-Apple-Dev mailing list SCAP-On-Apple-Dev(a)lists.macosforge.org<mailto:SCAP-On-Apple-Dev@lists.macosforge.org> https://lists.macosforge.org/mailman/listinfo/scap-on-apple-dev

3 3

[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

Re: [SCAP-On-Apple-Dev] Configuration Profiles vs Plist file diddling
by David Solin 03 Jun '13

03 Jun '13

(I cross-posted the message below to the OVAL developer list, but had to trim it to under 40k and re-post for this list) It sounds like, since the profile information is not resident on disk in the form of a plist, XML or text file, there's a need for a new test in the OVAL Mac schema -- a i.e., a profile_test, which would extract the profile as described below. Such a test could be designed like the upcoming plist511_test, to use XPATH to query the profile. If so, I would strongly urge interested parties to bring such a recommendation to the attention of the OVAL board, so that it will be possible to create useful SCAP content by the time OVAL 5.11 is finalized. Otherwise, an even longer wait will be ahead of us all. Regards, --David Solin > -------- Original Message -------- > Subject: Re: [SCAP-On-Apple-Dev] Configuration Profiles vs Plist file > diddling > Date: Fri, 31 May 2013 18:24:27 -0400 > From: Josh Wisenbaker <dubs(a)apple.com> > To: Haynes, Dan <dhaynes(a)mitre.org> > > > > > CC: scap-on-apple-dev(a)lists.macosforge.org > <scap-on-apple-dev(a)lists.macosforge.org>, OVAL <oval(a)mitre.org> > > > I think that there needs to be a bit of a mental reset as to how to > validate settings on the Mac as checking on-disk files doesn't > actually verify much and it really hasn't for some time now. For > example let's take a look at the loginwindow settings. The current > tests would look at a file to see if the settings are there. > > On my test Mac I have the test profile that I made installed. Because > I'm doing things with policy, it doesn't exist in the plists or domains. > > server:~ localadmin$ defaults -currentHost read com.apple.loginwindow > { > TALAppsToRelaunchAtLogin = ( > { > BackgroundState = 2; > BundleID = "com.apple.terminal"; > Hide = 0; > Path = "/Applications/Utilities/Terminal.app"; > }, > { > BackgroundState = 2; > BundleID = "com.apple.finder"; > Hide = 0; > Path = "/System/Library/CoreServices/Finder.app"; > } > ); > } > > Lets try another! > > server:~ localadmin$ defaults read > /Library/Preferences/com.apple.loginwindow.plist > { > OptimizerLastRunForBuild = 25364928; > OptimizerLastRunForSystem = 168297216; > lastUser = loggedIn; > lastUserName = localadmin; > } > > Hmm. Not there either. Maybe just the basic domain? > > server:~ localadmin$ defaults read com.apple.loginwindow > { > TALLogoutReason = Restart; > } > > No. Not there either! Well crap. Logging out though shows me that the > settings are applied! > > I can't really check the mobileconfig files either since they get > turned into a binary blob upon installation > in /var/db/ConfigurationProfiles/Store > > So what can I do? > > Well the first thing is that we can ask if there are profiles installed! > > server:~ localadmin$ profiles -H > profiles are installed on this system > > Sweet! But now what? > > Now we actually have several options, the easiest is to grab the > profile data right from the profiles command as XML. You can also get > this from system_profiler, and if you are using directory services > based policy you can get it from dscl or mcxquerey as well. > > server:~ localadmin$ sudo profiles -Pv -o Output.xml > profiles: verbose mode ON > profiles: outputPath = Output.xml > There are 1 configuration profiles installed > pass > > server:~ localadmin$ less Output.xml > > SNIP… > > <dict> > <key>PayloadContent</key> > <dict> > <key>loginWindowIdleTime</key> > <integer>900</integer> > <key>loginWindowModulePath</key> > <string>/System/Library/Screen Savers/Flurry.saver</string> > </dict> > <key>PayloadDisplayName</key> > <string>Login Window: Screen Saver Preferences</string> > <key>PayloadIdentifier</key> > <string>com.apple.mdm.server.example.private.a55249a0-ab8d-0130-272f-001c42d3e5bf.alacarte.loginwindow.6e51c520-ab8e-0130-2731-001c42d3e5bf.screensaver</string> > <key>PayloadType</key> > <string>com.apple.screensaver</string> > <key>PayloadUUID</key> > <string>42a5182d-2af5-dfa8-16b8-d3a3a88c37fb</string> > <key>PayloadVersion</key> > <integer>1</integer> > </dict> > > …SNIP > > As we can see, the only way to tell if this policy has been applied > with a modern method like a configuration profile is to check using > tools that are configuration profile aware. > > For settings that use profiles this makes everything much simpler. You > can simply ask for the output of the profiles command and then parse > it with XPath or what not. You get all the settings in one place and > you don't need to run around tracking down config files. > > Thanks, > Josh > > -- > Josh Wisenbaker > Consulting Engineer - Apple U.S. Commercial and Governmental Sales > dubs(a)apple.com <mailto:dubs@apple.com> > -- jOVAL.org: SCAP Simplified. Learn More <http://www.joval.org> | Features <http://www.joval.org/features/> | Download <http://www.joval.org/download/>

2 1

Re: [SCAP-On-Apple-Dev] Anyone have access to the DISA SCAP scanner?
by Josh Wisenbaker 03 Jun '13

03 Jun '13

Hi Danny, I suppose a bit of an introduction from myself would help here. I'm Josh Wisenbaker and I'm a peer of Shawn's at Apple on the CE team. I cover the client management and deployment subject matter and do a bit of Mac App Dev coverage as well. So while I'm not a contractor, I have done plenty of work over the years with gov and mil accounts. Josh -- Josh Wisenbaker Consulting Engineer - Apple U.S. Commercial and Governmental Sales dubs(a)apple.com On May 31, 2013, at 12:30 PM, "Haynes, Dan" <dhaynes(a)mitre.org> wrote: > Hi Josh, > > I guess I forgot to ask, are you supporting the U.S. government as a contractor? > > Thanks, > > Danny > > > From: Haynes, Dan > Sent: Friday, May 31, 2013 12:03 PM > To: 'Josh Wisenbaker'; scap-on-apple-dev(a)lists.macosforge.org > Subject: RE: [SCAP-On-Apple-Dev] Anyone have access to the DISA SCAP scanner? > > Hi Josh, > > The SPAWAR SCC tool is limited to U.S. government agencies and supporting contractors. I will put you in touch with the SPAWAR team to see if you are eligible. > > If not, there are quite a few other tools available (some commercial and some open source). You can find them at the following links. > > http://nvd.nist.gov/scapproducts.cfm > > http://oval.mitre.org/adoption/productlist.html > > Thanks, > > Danny > > From: scap-on-apple-dev-bounces(a)lists.macosforge.org [mailto:scap-on-apple-dev-bounces@lists.macosforge.org] On Behalf Of Josh Wisenbaker > Sent: Friday, May 31, 2013 11:52 AM > To: scap-on-apple-dev(a)lists.macosforge.org > Subject: [SCAP-On-Apple-Dev] Anyone have access to the DISA SCAP scanner? > > Does anyone have access to the SCC 3.1 that is posted on the DISA page here? <http://iase.disa.mil/stigs/scap/index.html> > > From the screenshots I've seen it looks like a Java tool. > > Josh > > -- > Josh Wisenbaker > Consulting Engineer - Apple U.S. Commercial and Governmental Sales > dubs(a)apple.com

2 3

Anyone have access to the DISA SCAP scanner?
by Josh Wisenbaker 31 May '13

31 May '13

Does anyone have access to the SCC 3.1 that is posted on the DISA page here? <http://iase.disa.mil/stigs/scap/index.html> From the screenshots I've seen it looks like a Java tool. Josh -- Josh Wisenbaker Consulting Engineer - Apple U.S. Commercial and Governmental Sales dubs(a)apple.com

3 2

Configuration Profiles vs Plist file diddling
by Josh Wisenbaker 31 May '13

31 May '13

Hi all, I think that from an audit and remediation standpoint things can be greatly simplified by using Configuration Profiles. You can easily get a XML formatted list of the composited policies that are on the Mac and you can easily apply settings by installing a profile. Using the policy mechanisms in OS X is highly recommended over messing with files. As an example here is a profile I made that implements all of the settings for the initial loginwindow tickets that are in the tracker. This profile allows for removal without authentication so it's easy to test with. Thoughts? Josh -- Josh Wisenbaker Consulting Engineer - Apple U.S. Commercial and Governmental Sales dubs(a)apple.com

2 1

[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