scap-security-guide August 2020

scap-security-guide@lists.fedorahosted.org

6 participants
4 discussions

Re: Refresh of how we track a profile - tracking the policy
by Watson Sato 17 Aug '20

17 Aug '20

On Tue, Aug 11, 2020 at 1:24 AM Shane Boulden <sboulden(a)redhat.com> wrote: > I like that the proposal adds "policy_hub", "version" and > "comes_into_force" into the profile file (with the assumption that this > will not make it into XCCDF). Having this information directly in the > .profile file makes it simpler for users and partners to see the current > state. > > I see an issue with maintainers - we can mix up at least GH usernames and >> e-mails - what about considering it a list of dicts, so we could have e.g. >> maintainers: >> - github: redhatrises >> - github: yuumasato >> email: wsato(a)redhat.com > > Could we use coThe idea to use cocdeowners > <https://docs.github.com/en/github/creating-cloning-and-archiving-repositori…> > instead to track profile maintainers? This way the profile owners will be > immediately notified when a PR is opened for a .profile file, and avoids > having to maintain dicts of username->email mappings (it's simply tied to > the GH username) > The automatic notifications of codeowners make it very interesting. I have two remarks though: 1. maintenance of the codeowners file, which needs to be done by admins or owners; 2. permissions, codeowners need to have write permission for the repo; This centralizes the management of Profile "ownership" and increases requirements on the codeowners. > On Mon, Aug 10, 2020 at 8:18 PM Matej Tyc <matyc(a)redhat.com> wrote: > >> I have remarks to Gabe's remarks, but I add them to Watson's reply, so >> the thread doesn't bifurcate. >> On 10. 08. 20 10:22, Watson Sato wrote: >> >> >> On Sat, Aug 8, 2020 at 12:10 AM Gabe Alford <redhatrises(a)gmail.com> >> wrote: >> >>> Anything that is metadata should conform to the Dublin Core per the >>> XCCDF specification for the .profile files, or it can be a commented out >>> section at the top of the .profile. >>> >> As the purpose is to record key properties of the profile, I am not in >> favor of specifying them as comments - one can't parse them reliably, and >> as we would like this to save us some work, we want to have at most one >> schema that can be approached by computers. >> >> Next, the schema presented by Watson reflects what we think is useful to >> record. I wouldn't compromise here because of the Dublin thing. I >> understand this as a resource for content authors, it could possibly be >> inserted as a table into the profile description, and we could have a test >> that key profiles have this record. Putting this info into profile XCCDF >> metadata makes sense, but I wouldn't use this as a factor that would >> restrict the data set that we would like to record. >> >> I didn't envision this metadata to be included in the built XCCDF >> profile, so I didn't look into the formal syntax. >> And it is laid out as yaml to ease any eventual build system future >> automation. >> >> >>> Alternatively, a single file like maintainers or profile maintainers >>> would be better as a single source of truth. >>> >> >> That could work too, in this case I would make the file per product, to >> keep them simple. >> >> I don't get the single source of truth thing - wouldn't it be the >> respective profile file? Typically, one is interested in who maintains a >> particular profile, not in how many profiles one person maintains. But more >> importantly, I think it is important to see who maintains the profile when >> one edits the profile file, or when one reviews the change. Having two >> files - one with the profile definition, and the other one that may or may >> not contain information about possible profile stakeholders - is cumbersome. >> >> >>> nitpick: I think that "comes_into_force" should be something else like >>> "when", "applicability", or "profile_enforcement". >>> >> >> Thank you for the suggestions, I was not sure what would be a good name >> for the field. >> >> But this also makes me wonder if tracking this is even necessary as >>> technically in all compliance regimes a newly released profile becomes >>> applicable on release. >>> >> >> The core of this field is clarity and understanding how the policy is >> applied in practice, if it is the case that all policies and profiles are >> instantly unusable when a new version is released, >> this field is unnecessary. >> The proposal for "comes_into_force" assumed that the organizations >> implementing and/or enforcing the policy don't update instantly, and have a >> time frame to adapt. >> >> I see this as a possibility to at least loosely define shape of profiles >> - if a stakeholder claims that they expect the profile to be behind at most >> six months, then comparison of a couple of numbers can quickly tell us >> whether the profile is good, on track, or whether it was left behind. >> >> Below is a draft proposal of a set of *optional* metadata to be added to >> the ".profile" file. Everything is pretty much free form and optional. >> >> - policy_hub: (URL pointing to page or organization that publishes >> the policy) >> - version: (version of the policy implemented) >> - comes_into_force: (text stating when a policy starts being >> enforced, in other words, when a policy version is in practice obsolete) >> - maintainers: (contact of policy SME, stakeholder, or person >> responsible for the profile, can be in form of GitHub handle for example) >> >> I see an issue with maintainers - we can mix up at least GH usernames and >> e-mails - what about considering it a list of dicts, so we could have e.g. >> >> maintainers: >> >> - github: redhatrises >> - github: yuumasato >> email: wsato(a)redhat.com >> >> >> >>> >> On Fri, Aug 7, 2020 at 9:21 AM Watson Sato <wsato(a)redhat.com> wrote: >>> ... >>> >> -- Watson Sato Security Technologies | Red Hat, Inc

3 5

Refresh of how we track a profile - tracking the policy
by Watson Sato 10 Aug '20

10 Aug '20

Hello all, With the increasing number of products and profiles in ComplianceAsCode/content, keeping track of the policies, profiles and people involved has become more complex. In an effort to better maintain the profiles in the project, I'm looking for a way to have the following questions easily answered WRT to a profile: - Who should be consulted in case of questions about how a profile aligns (or should be aligned) with the policy? - Where does one get to know about new policy releases? - When is a policy version considered out of date? Below is a draft proposal of a set of *optional* metadata to be added to the ".profile" file. Everything is pretty much free form and optional. - policy_hub: (URL pointing to page or organization that publishes the policy) - version: (version of the policy implemented) - comes_into_force: (text stating when a policy starts being enforced, in other words, when a policy version is in practice obsolete) - maintainers: (contact of policy SME, stakeholder, or person responsible for the profile, can be in form of GitHub handle for example) Here is an example of how it can look like. (I have used profiles with known implicit maintainers or SMEs, in CC): https://github.com/yuumasato/scap-security-guide/commit/ba967716ef966048357… I think these data will bring profile transparency to project maintainers, and profile maintainers can be kept in the loop with regards to changes in the profiles they care about. Let me know what you think about it, do you have other ideas? -- Watson Sato Security Technologies | Red Hat, Inc

3 3

Support for SSG checks?
by N B 10 Aug '20

10 Aug '20

Could anyone speak to SSG support for check content written for SCE (vs. OVAL)? The developer's guide (section 7 intro) implies XCCDF check content is not required to be in OVAL, but in fleshing out support for checks later in that section it's hard to see how anything but shorthand OVAL could be supported. If not SCE directly, might it be possible to somehow use raw XCCDF snippets to incorporate SCE check content? I'm on the hook to support some custom content for an internal need, and have found OVAL to be a bit inflexible (unless I want to propose extensions to OVAL itself which is a bit beyond the scope I can take on at the moment). One example is retrieving additional metadata from an RPM beyond what OVAL's rpminfo supports. Admittedly, since my effort is internal, I'm misusing SSG in the sense that I wouldn't be contributing the custom content back to the SSG repo. SSG still offers an excellent framework for my isolated situation though, except that without support for non-OVAL checks, I'm not sure if I can author the content i need with it.

3 6

Approach to allow support of UEFI grub2 for grub2_audit_argument rule
by Andy Coates 03 Aug '20

03 Aug '20

Hi All, First I'm jumping in the deep end with this - I've only just discovered the ComplianceAsCode/content repo and whilst loving the design and flexibility, as a newbie it is very daunting to ingest how all the rules are generated and interact, but it is very logical as I start to understand it more. I'm currently looking at the linux rule grub2_audit_argument which uses shared/templates/template_OVAL_grub2_bootloader_argument to create the OVAL definitions. The problem is the template hardcodes the grub path to /boot/grub2/grub.cfg, but with UEFI, just like the rule documentation warns, it will be /boot/efi/EFI/redhat/grub.cfg or /boot/efi/EFI/fedora/grub.cfg. So the rule describes what should be checked and which files to audit for both BIOS and UEFI versions, but the actual criteria check only supports the BIOS/default path. So I was curious what the approach would be for adding support to this. I see other OVAL tests that use a shared OVAL check to test (extend) if the system is UEFI or not, and pass those that aren't - and will then have a counterpart rule just for UEFI, so both rules can exist and be checked. As the grub2_audit_argument rule is using a template, the template isn't UEFI aware, and doesn't create two rules for both UEFI and non-UEFI that could use the shared extended OVAL check for UEFI. There are conditionals in the template for RHEL or others, to determine what content should be checked, but I can't see how you could use a conditional for UEFI path or not. If I create two rules that use the same template and pass in different arguments (e.g. UEFI or not), then the test names duplicate and the build complains. These are just the things I've thought about uplifting from my limited experience. What would be right way of adding in that path support for UEFI based systems? I'm also surprised others wouldn't notice/report this, so perhaps I'm misunderstanding something. Thanks! Andy.

4 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide August 2020