##OpenSource Security Working Group Agenda
##May 20, 2022
Moderator: Suse
Next Meeting Date: Jun 17, 2022
Next Meeting Moderator: Red Hat
Communication Channel (CaC): https://gitter.im/Compliance-As-Code-The/content
Agenda:
-
Group(s) check-in
-
June is coming fast, would like to have a draft, but need everyone’s input.
##Apr 22, 2022
Moderator: Canonical (If unable, Red Hat can cover it)
Next Meeting Date: May 20th, 2022
Next Meeting Moderator: Suse
Communication Channel (CaC): https://gitter.im/Compliance-As-Code-The/content
Agenda:
-
Red Hat will present initial work on white papers for discussion: Both Documents have been added to the github (see Below)
-
Red Hat would like to open discussion on each initial doc for feedback and to brainstorm additions/changes/recommendations for each document.
-
Notes/Discussion: (Enter Below)
##Mar 18, 2022
Moderator: Canonical (Blaine did as they had conflict)
Next Meeting Date: 03/18/22
Next Meeting Moderator: Canonical
Communication Channel (CaC): https://gitter.im/Compliance-As-Code-The/content
Agenda:
-
Group Overview: Working out ways we can provide collective guidance for DISA (hardened images) on OS and Container Security
-
Need to get names of group member participants from Suse/Canonical
-
-
Need to get the working groups members connected so they can start communicating.
-
What is a hardened image
-
RH (Ash Westbrook) - wanted to be as agnostic as possible
-
Do we check on install or continuously?
-
Config vs monitoring and drift
-
How to adapt to changing standards
-
Ex disable unpriv ebpf
-
-
? What are we doing to not reinvent what is in NIST control lists?
-
New, missed, things we care about?
-
Take and target the focus on the NIST controls
-
Do we directly reference the material or ignore it?
-
We should reference and relate
-
-
Identify the “I don’t think this does what you think it does”
-
Identify the the blindspots around these controls
-
-
-
NIST and DISA’s implementation of the controls - one size fits all doesn’t really work - important for us to divide out for where they are employed.
-
Many things in the STIGS that are blindly deployed that are not applicable
-
-
-
Location and workload type should have guidance
-
-
Container Security
-
Two types - container image or runtimes or both?
-
How much overlap will there be with the hardened linux? (OS vs containers)
-
Focus on what the 3 of us have in common - the theory and rules should be roughly the same.
-
Concentrating on security best practices
-
Cover overlap between the 3
-
Environment
-
Where deployed vs how deployed
-
Specific implementation
-
Auditing
-
-
-
What is the scope -
-
Narrowly focusing on the actions performed on building or focusing on scanning when container is pulled? Or are we extending it to the process to have continuous improvement of “securing” it.
-
Is this 1 Whitepaper or many?
-
What should be done initially, and then how do you handle configuration drift? How do you maintain compliance?
-
Initial - how to do it on standup
-
Later - how to maintain and daily runtime maintenance of security
-
We want to call out and help to set the Standard for what the community adopts and expects.
-
Scope - setting and accepting the risks of the source into creating the image? We have set the bar - where you get the source of the image and work your way out. (this seems to be the right path to take). Start with the assumption and progress from there.
-
We need to set the principles, make sure the source is trusted, and that it is aligned with the end-goal principles from the beginning.
-
-
-
-
Goal is to have initial whitepaper set by June
-
-
Need to have specific guidance for containers and STIG (hardening) that makes sense for deployment
-
Containers are not a General Purpose Operating System (GPOS)
-
Some are technical powerhouses trying to deploy
-
Others are smaller, need security, but need help with the execution and deployment to do it right
-
What do I do first?
-
Where do I start
-
They have been underserved.
-
-
-
-
Concerns to create the image that security is something that is just “the press of the button”
-
Hardening is more than just settings
-
How do you know what should be allowed vs forbidden? How do they know that it is working correctly?
-
Need to keep focus on the complexity of the idea, help to point to where to find help
-
This could be a large effort to meet all the concerns - we need to determine the standard and provide the guidance to what the standard should be.
-
Scaffolding the assistance should be up to the companies and partners to provide the applications
-
-
-
Linus is based on modules or types of granularity
-
The steps of hardening depend on the types and kinds of packages you have installed
-
What is the base, maybe create a modular standard for different types of deployments.
-
Could the packages provide hardening guidance if they are installed
-
Create a technical standard that brings in the hardening recommendations as the packages, or workloads are installed? (may be technical implementation)
-
Focus on standard across the board
-
FIPS, root, example may be too much minutiae
-
-
-
-
Focus on our recommendations on how we should harden secure a containerized workload
-
-
Theories around fundamentals
-
-
AI: Blaine will send and email with the names we have so far to help lead the working groups from each company, will start to connect them so they can start working together offline in between monthly sessions.
-
Workgroup Updates
-
Will start working and collaborating.
-
##Feb 18, 2022
Moderator: Steering Committee
Next Meeting Date: 03/18/22
Next Meeting Moderator: Canonical
Communication Channel (CaC): https://gitter.im/Compliance-As-Code-The/content
Agenda:
-
Welcome, guidance, housekeeping
-
Collaboration space:
-
What we need…
-
Rotating Moderation (alphabetical by company)
-
-
Introduction of WG Topics
-
“What makes Linux hardened (OS)?”
-
“What is a hardened container?”
-
-
Notes:
-
Introduction,housekeeping
-
Decisions: Working groups work async (collab in space between meetings) and then update the working group in the monthly meeting. Goal date of Jul 1, 2022 to have a publishable collaborative white paper available to the community.
-
Questions:
-
Need to see representatives from CIS/DISA/others. Can we see more of their contributions?
-
This is the goal - they will provide more once they see we have valuable information to start with. They want to see that we are invested, and providing targeted advice, valuable opinions.
-
-
Thinking about upstream projects (like Compliance as Code) - need to know how it relates to the standing of the standards by DISA.
-
One of the projects that could benefit from this work.
-
Add in specific certification issues - to drive easier mapping and contributions that meet the needs of meeting the certifications and profile requirements.
-
-
-
Who will drive/lead the working groups? (Take home AI - with first collaboration sessions to set. Group leaders emailed to Blaine/Amy by end of next week (Feb 25)) - at least one person per company and be willing to work in the CaC workspace where needed.
-
DISA/etc will not join right away - may we think from different PoV - each vendor to ask specific set of questions to understand our clients needs? When we know these needs, then we can know what the goals of the future workshops should be?
-
Agreed - we share in a way that allows us to collab
-
Think about sufficiency - are we fully or partially supporting it? How do we know when we are compliant/complete? (CaC application)
-
Customers are asking us for help “what does hardening mean?” - STIG is very long and hard to understand and does it fully protect? Or just a niche environment? Other options are the more generic (guidelines) of the BSI (german standards) - how do you secure an IT landscape, and is modularized.
-
Refine over time
-
Be able to answer the right questions over the right topics
-
Needs to be a top-down approach - and how to get comprehensive approach (question/answer approach)
-
-
-
-
AIs:
-
Fill in working group members (email to Blaine Stone or Amy Farley by end of next week (Feb 25))
-
Set the working group leaders from each of the vendors, (email to Blaine Stone or Amy Farley by end of next week (Feb 25))
-
Working groups encouraged to start working together by March 4th, 2022.(email to Blaine Stone or Amy Farley by end of next week (Feb 25))
-
(email to Blaine Stone or Amy Farley by end of next week (Feb 25)) *
-
-
##Steering Committee:
Company |
Contributor |
Role |
|
Canonical |
Mossimo |
||
Red Hat |
Amy Farley |
Product Manager - Security |
|
Red Hat |
Andrea Hall |
||
SUSE |
Blaine Stone |
||
##Contributors: (Working Group Leaders will have ** by name and bold focus)
| Company | Contributor | Role | Topic Focus (OS/Container/Both) | |
|---|---|---|---|---|
Canonical |
||||
Red Hat |
Product Owner - Compliance |
Both |
||
Red Hat |
||||
SUSE |
||||
Red Hat |
Ian Tewksbury** |
Senior Principal Architect |
Containers |
|
Red Hat |
Gus Parvin |
Principal Software Engineer |
Containers |
|
Red Hat |
Kevin O’Donnell |
Senior Principal Architect |
Both |
|
Red Hat |
Kenny Peeples |
Principal Architect |
Both |
|
Red Hat |
Trevor Bryant |
Solution Architect |
Both |
|
Red Hat |
Joshua Loscar |
Senior Technical Account Manager |
Both |
|
Red Hat |
Mark Salowitz** |
Secure Infrastructure Architect |
Linux |
|
Red Hat |
Steven Grubb |
Senior Principal Software Engineer |
Both |
|
Red Hat |
Ash Westbrook |
Senior Field Product Manager |
Both |
##Companies/Moderation Rotation
Company |
Moderation (move * down after each meeting) |
Canonical |
Mar 18, 2022 |
CIS |
|
DISA |
|
Red Hat |
|
SUSE |