opencontrol / discuss Goto Github PK
View Code? Open in Web Editor NEWa place to have conversations about OpenControl projects
Home Page: https://github.com/opencontrol/discuss/issues
License: Other
a place to have conversations about OpenControl projects
Home Page: https://github.com/opencontrol/discuss/issues
License: Other
While the current community is small and primarily focused on their day to day work; the concept/appeal/potential of Open Control is immense. Open Control (to me atleast) establishes the fundamental concept needed to make compliance-as-code a reality; in that it takes a "component" first/focused approach to the component <-> control relationship.
My hope with the issue is to discuss the current and potential scope/domain of OpenControl. Highlight some potential areas where it could be expanded to be more functional/practical for use as compliance-as-code that could generate a documentation needed for traditional SSP/Auditor needs.
Currently OpenControl is limited to mapping to NIST 800-53 controls, for standard SSP(s) and FEDRAMP usage this is sufficient but the schema should address other control regimes like some of those referenced in various SCAP content:
References:
oval: # OVAL vulnerability ID
cce: # CCE vulnerability ID
nist: # NIST-800 Control ID
disa: # DISA STIG ID
cis: # Center for Internet Security ID
ossrg: # General Purpose Operating System SRG
?pci: # Payment Card Industry Data Security Standard (PCI DSS)
?hipaa: # Health Insurance Portability and Accountability Act
?sox: # Sarbanes-Oxley Act of 2002 (SOX)
See issue on OpenScap Security Guide
System Interconnections, relationships, and architecture are hard to define in code but it is an essential need to bridge the gap between actual system architecture and its security documentation.
While difficult I think there is atleast one open standard that does this well. OASIS TOSCA specification/standard was created for application stack portability across cloud providers; one aspect of it is how it manages to codify topology using a relationship/node model:
nodeType
or capabilities
.relationships
.Key | Value |
---|---|
nodeType | Root; Compute; SoftwareComponent; DBMS; Database; Webserver; WebApplication; BlockStorage; ObjectStorage; Load Balencer |
capabilities | OperatingSystem; Endpoint; Endpoint.Admin; Endpoint.Public; Scalable; Endpoint.Database; Attachment; network.Linkable; network.Bindable; OperatingSystem; Container.Docker |
relationships | HostedOn; ConnectsTo; AttachesTo; RoutesTo; network.LinksTo; network.BindsTo |
How to manage/combine controls when inheriting/applying controls to/from various levels within the architecture?
IDEA
level: Infrastructure, Platform, Software, Others? (Monitoring, Security, etc.)
How to manage components and policies in yaml, as currently Policies are handled else where as Markdown or Word Documents?
IDEA
type: Component, Policy
Fundamental to SSP(s) is who's responsible and "separation of duties". How could OpenControl best handle hybrid component ownership/maintenance models. Also how could traditional roles/responsibilities be integrated into documentation for boundary accreditation/inheritance and the like?
These are other common data points within an SSP too?
This last one is the most obvious example of overlap with config management; but all of the items above are examples of whereby expanding the scope/domain of OpenControl would overlap and/or be redundancy with actionable Configuration Management and Automation solutions like (just an off the cuff list):
- Ansible
- BOSH
- Brooklyn (Apache)
- Capistrano
- CFengine
- Chef
- Docker
- Fabric
- Puppet
- Saltstack
- Terraform
- TOSCA (OASIS / Openstack Heat)
So I think one fundamental Question for the OpenControl model, is how it can best serve as that overlay for documentation but then be extendable/pluggable/mappable/etc to these various solutions rather then requiring redundancy in data points.
I know this issue is all over the place but I think aside from the governance policy discussion #5 this is a major unknown and may lead to others thinking OpenControl is/will be something that it is not...
Hi All,
I took a look at Open Control in the past and really wanted to like it but it was just too unweildy for what I needed.
I would like to work to get Open Control into SIMP (https://github.com/NationalSecurityAgency/SIMP or https://github.com/simp).
Our present security documentation is generated from RestructuredText since that was easier for our users to deal with overall and is automatically processed by ReadTheDocs. The latest version can be found at http://simp.readthedocs.io/en/master/security_conop/index.html and http://simp.readthedocs.io/en/master/security_mapping/index.html. This is generated from https://github.com/simp/simp-doc.
The last time we used Open Control, we found the following limitations:
Inability to link between sections promoting a great deal of copy/paste text
Inability to link directly to the referencing documentation
Inability to have easy overrides of sections
Inability to compose the SSP from an application point of view
Ability to run without connectivity to the Internet
Inability to output to something that we could easily import to ReadTheDocs (RestructuredText)
We've recently added the ability to actually validate that our Puppet code parameters are correct per policy and we have a prototype working that will let us switch our entire parameter sets from a given policy to another at the change of a single variable.
Additionally, we're starting to work with the Inspec team from Chef to integrate Inspec directly into our acceptance testing framework.
Since we're pushing forward with so many compliance-focused components, it seemed like a good time to reach out and see if Open Control is right for the project.
Thanks in advance!
Right now we have the FedRAMP-Certifications repo. I'd like to expand the certifications to cover things like FISMA and 800-171/Controlled Unclassified.
One option would be to create multiple new repos, e.g. opencontrol/fisma-certifications
, opencontrol/cui-certifications
, but that seems unmanagable and slightly annoying.
Should a opencontrol/certifications
be created instead?
e.g.
opencontrol/certifications
---- FedRAMP-low.yaml
---- FedRAMP-mod.yaml
---- FedRAMP-high.yaml
---- cui.yaml
---- etc
Has been incorporated into https://github.com/opencontrol/standards for over a year
NIST has done a relatively great job (IMHO) of translating/mapping the RMF to NIST-800-53 through the NIST Framework for Improving Critical Infrastructure Cybersecurity
Considering the highlevel controls are already mapped we should be able to parse out control enhancements `i.e. those additional questions based on whether a system is Low/Moderate/High) to their root control and map that back to the framework as a way to assess how a system is addressing RMF using the mappings provided by NIST
For reference only on existing control mappings:
https://gist.github.com/JJediny/65438415b5e38ac7560ad5f5597f1877
Updated: 1/13/2017 - Updated with Draft v1.1 https://www.nist.gov/cyberframework/draft-version-11
NIST CSF has three levels: Function -> Category -> Subcategory
###################
# Subcategory #
###################
-
Category: ID.AM
Subcategory: 1
Description: Physical devices and systems within the organization are inventoried
Component:
Control:
- CM-8
-
Category: ID.AM
Subcategory: 2
Description: Software platforms and applications within the organization are inventoried
Component:
Control:
- CM-8
-
Category: ID.AM
Subcategory: 3
Description: Organizational communication and data flows are mapped
Component:
Control:
- AC-4
- CA-3
- CA-9
- PL-8
-
Category: ID.AM
Subcategory: 4
Description: External information systems are cataloged
Component:
Control:
- AC-20
- SA-9
-
Category: ID.AM
Subcategory: 5
Description: Resources (e.g., hardware, devices, data, time, and software) are prioritized based on their classification, criticality, and business value
Component:
Control:
- CP-2
- RA-2
- SA-14
-
Category: ID.AM
Subcategory: 6
Description: Cybersecurity roles and responsibilities for the entire workforce and third-party stakeholders (e.g., suppliers, customers, partners) are established
Component:
Control:
- CP-2
- PS-7
- PM-11
-
Category: ID.BE
Subcategory: 1
Description: The organization’s role in the supply chain is identified and communicated
Component:
Control:
- CP-2
- SA-12
-
Category: ID.BE
Subcategory: 2
Description: The organization’s place in critical infrastructure and its industry sector is identified and communicated
Component:
Control:
- PM-8
-
Category: ID.BE
Subcategory: 3
Description: Priorities for organizational mission, objectives, and activities are established and communicated
Component:
Control:
- PM-11
- SA-14
-
Category: ID.BE
Subcategory: 4
Description: Dependencies and critical functions for delivery of critical services are established
Component:
Control:
- CP-8
- PE-9
- PE-11
- PM-8
- SA-14
-
Category: ID.BE
Subcategory: 5
Description: Resilience requirements to support delivery of critical services are established for all operating states (e.g. under duress/attack, during recovery, normal operations)
Component:
Control:
- CP-2
- CP-11
- SA-14
-
Category: ID.GV
Subcategory: 1
Description: Organizational information security policy is established
Component:
Control:
- All
-
Category: ID.GV
Subcategory: 2
Description: Information security roles & responsibilities are coordinated and aligned with internal roles and external partners
Component:
Control:
- PM-1
- PS-7
-
Category: ID.GV
Subcategory: 3
Description: Legal and regulatory requirements regarding cybersecurity, including privacy and civil liberties obligations, are understood and managed
Component:
Control:
- All
-
Category: ID.GV
Subcategory: 4
Description: Governance and risk management processes address cybersecurity risks
Component:
Control:
- PM-9
- PM-11
-
Category: ID.RA
Subcategory: 1
Description: Asset vulnerabilities are identified and documented
Component:
Control:
- CA-2
- CA-7
- CA-8
- RA-3
- RA-5
- SA-5
- SA-11
- SI-2
- SI-4
- SI-5
-
Category: ID.RA
Subcategory: 2
Description: Cyber threat intelligence is received from information sharing forums and sources
Component:
Control:
- PM-15
- PM-16
- SI-5
-
Category: ID.RA
Subcategory: 3
Description: Threats, both internal and external, are identified and documented
Component:
Control:
- RA-3
- SI-5
- PM-12
- PM-16
-
Category: ID.RA
Subcategory: 4
Description: Potential business impacts and likelihoods are identified
Component:
Control:
- RA-2
- RA-3
- PM-9
- PM-11
- SA-14
-
Category: ID.RA
Subcategory: 5
Description: Threats, vulnerabilities, likelihoods, and impacts are used to determine risk
Component:
Control:
- RA-2
- RA-3
- PM-16
-
Category: ID.RA
Subcategory: 6
Description: Risk responses are identified and prioritized
Component:
Control:
- PM-4
- PM-9
-
Category: ID.RM
Subcategory: 1
Description: Risk management processes are established, managed, and agreed to by organizational stakeholders
Component:
Control:
- PM-9
-
Category: ID.RM
Subcategory: 2
Description: Organizational risk tolerance is determined and clearly expressed
Component:
Control:
- PM-9
-
Category: ID.RM
Subcategory: 3
Description: The organization’s determination of risk tolerance is informed by its role in critical infrastructure and sector specific risk analysis
Component:
Control:
- PM-8
- PM-9
- PM-11
- SA-14
-
Category: ID.SC
Subcategory: 1
Description: Cyber supply chain risk management processes are identified, established, assessed, managed, and agreed to by organizational stakeholders
Component:
Control:
- SA-9
- SA-12
- PM-9
-
Category: ID.SC
Subcategory: 2
Description: Identify, prioritize and assess suppliers and partners of critical information systems, components and services using a cyber supply chain risk assessment process
Component:
Control:
- RA-2
- RA-3
- SA-12
- SA-14
- SA-15
- PM-9
-
Category: ID.SC
Subcategory: 3
Description: Suppliers and partners are required by contract to implement appropriate measures designed to meet the objectives of the Information Security program or Cyber Supply Chain Risk Management Plan.
Component:
Control:
- SA-9
- SA-11
- SA-12
- PM-9
-
Category: ID.SC
Subcategory: 4
Description: Suppliers and partners are monitored to confirm that they have satisfied their obligations as required. Reviews of audits, summaries of test results, or other equivalent evaluations of suppliers/providers are conducted
Component:
Control:
- AU-2
- AU-6
- AU-12
- AU-16
- PS-7
- SA-9
- SA-12
-
Category: ID.SC
Subcategory: 5
Description: Response and recovery planning and testing are conducted with critical suppliers/providers
Component:
Control:
- CP-2
- CP-4
- IR-3
- IR-4
- IR-6
- IR-8
- IR-9
-
Category: PR.AC
Subcategory: 1
Description: Identities and credentials are issued, managed, revoked, and audited for authorized devices, users, and processes
Component:
Control:
- AC-2
- IA
-
Category: PR.AC
Subcategory: 2
Description: Physical access to assets is managed and protected
Component:
Control:
- PE-2
- PE-3
- PE-4
- PE-5
- PE-6
- PE-9
-
Category: PR.AC
Subcategory: 3
Description: Remote access is managed
Component:
Control:
- AC‑17
- AC-19
- AC-20
-
Category: PR.AC
Subcategory: 4
Description: Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties
Component:
Control:
- AC-2
- AC-3
- AC-5
- AC-6
- AC-16
-
Category: PR.AC
Subcategory: 5
Description: Network integrity is protected, incorporating network segregation where appropriate
Component:
Control:
- AC-4
- SC-7
-
Category: PR.AC
Subcategory: 6
Description: Identities are proofed and bound to credentials, and asserted in interactions when appropriate
Component:
Control:
- AC-2
- AC-3
- AC-5
- AC-6
- AC-16
- AC-19
- AC-24
- IA-2
- IA-4
- IA-5
- IA-8
- PE-2
- PS-3
-
Category: PR.AT
Subcategory: 1
Description: All users are informed and trained
Component:
Control:
- AT-2
- PM-13
-
Category: PR.AT
Subcategory: 2
Description: Privileged users understand roles & responsibilities
Component:
Control:
- AT-3
- PM-13
-
Category: PR.AT
Subcategory: 3
Description: Third-party stakeholders (e.g., suppliers, customers, partners) understand roles & responsibilities
Component:
Control:
- PS-7
- SA-9
-
Category: PR.AT
Subcategory: 4
Description: Senior executives understand roles & responsibilities
Component:
Control:
- AT-3
- PM-13
-
Category: PR.AT
Subcategory: 5
Description: Physical and information security personnel understand roles & responsibilities
Component:
Control:
- AT-3
- PM-13
-
Category: PR.DS
Subcategory: 1
Description: Data-at-rest is protected
Component:
Control:
- SC-28
-
Category: PR.DS
Subcategory: 2
Description: Data-in-transit is protected
Component:
Control:
- SC-8
-
Category: PR.DS
Subcategory: 3
Description: Assets are formally managed throughout removal, transfers, and disposition
Component:
Control:
- CM-8
- MP-6
- PE-16
-
Category: PR.DS
Subcategory: 4
Description: Adequate capacity to ensure availability is maintained
Component:
Control:
- AU-4
- CP-2
- SC-5
-
Category: PR.DS
Subcategory: 5
Description: Protections against data leaks are implemented
Component:
Control:
- AC-4
- AC-5
- AC-6
- PE-19
- PS-3
- PS-6
- SC-7
- SC-8
- SC-13
- SC-31
- SI-4
-
Category: PR.DS
Subcategory: 6
Description: Integrity checking mechanisms are used to verify software, firmware, and information integrity
Component:
Control:
- SI-7
-
Category: PR.DS
Subcategory: 7
Description: The development and testing environment(s) are separate from the production environment
Component:
Control:
- CM-2
-
Category: PR.DS
Subcategory: 8
Description: Integrity checking mechanisms are used to verify hardware integrity
Component:
Control:
- SA-10
- SI-7
-
Category: PR.IP
Subcategory: 1
Description: A baseline configuration of information technology/industrial control systems is created and maintained incorporating appropriate security principles (e.g. concept of least functionality)
Component:
Control:
- CM-2
- CM-3
- CM-4
- CM-5
- CM-6
- CM-7
- CM-9
- SA-10
-
Category: PR.IP
Subcategory: 2
Description: A System Development Life Cycle to manage systems is implemented
Component:
Control:
- SA-3
- SA-4
- SA-8
- SA-10
- SA-11
- SA-12
- SA-15
- SA-17
- PL-8
-
Category: PR.IP
Subcategory: 3
Description: Configuration change control processes are in place
Component:
Control:
- CM-3
- CM-4
- SA-10
-
Category: PR.IP
Subcategory: 4
Description: Backups of information are conducted, maintained, and tested periodically
Component:
Control:
- CP-4
- CP-6
- CP-9
-
Category: PR.IP
Subcategory: 5
Description: Policy and regulations regarding the physical operating environment for organizational assets are met
Component:
Control:
- PE-10
- PE-12
- PE-13
- PE-14
- PE-15
- PE-18
-
Category: PR.IP
Subcategory: 6
Description: Data is destroyed according to policy
Component:
Control:
- MP-6
-
Category: PR.IP
Subcategory: 7
Description: Protection processes are continuously improved
Component:
Control:
- CA-7
- CP-2
- IR-8
- PL-2
- PM-6
-
Category: PR.IP
Subcategory: 8
Description: Effectiveness of protection technologies is shared with appropriate parties
Component:
Control:
- AC-21
- CA-7
- SI-4
-
Category: PR.IP
Subcategory: 9
Description: Response plans (Incident Response and Business Continuity) and recovery plans (Incident Recovery and Disaster Recovery) are in place and managed
Component:
Control:
- CP-2
- IR-8
-
Category: PR.IP
Subcategory: 10
Description: Response and recovery plans are tested
Component:
Control:
- IR-3
- PM-14
-
Category: PR.IP
Subcategory: 11
Description: Cybersecurity is included in human resources practices (e.g., deprovisioning, personnel screening)
Component:
Control:
- PS
-
Category: PR.IP
Subcategory: 12
Description: A vulnerability management plan is developed and implemented
Component:
Control:
- RA-3
- RA-5
- SI-2
-
Category: PR.MA
Subcategory: 1
Description: Maintenance and repair of organizational assets is performed and logged in a timely manner, with approved and controlled tools
Component:
Control:
- MA-2
- MA-3
- MA-5
-
Category: PR.MA
Subcategory: 2
Description: Remote maintenance of organizational assets is approved, logged, and performed in a manner that prevents unauthorized access
Component:
Control:
- MA-4
-
Category: PR.PT
Subcategory: 1
Description: Audit/log records are determined, documented, implemented, and reviewed in accordance with policy
Component:
Control:
- AU
-
Category: PR.PT
Subcategory: 2
Description: Removable media is protected and its use restricted according to policy
Component:
Control:
- MP-2
- MP-4
- MP-5
- MP-7
-
Category: PR.PT
Subcategory: 3
Description: The principle of least functionality is incorporated by configuring systems to provide only essential capabilities
Component:
Control:
- AC-3
- CM-7
-
Category: PR.PT
Subcategory: 4
Description: Communications and control networks are protected
Component:
Control:
- AC-4
- AC-17
- AC-18
- CP-8
- SC-7
-
Category: PR.PT
Subcategory: 5
Description: Systems operate in pre-defined functional states to achieve availability (e.g. under duress, under attack, during recovery, normal operations).
Component:
Control:
- CP-7
- CP-8
- CP-11
- CP-13
- PL-8
- SA-14
- SC-6
-
Category: DE.AE
Subcategory: 1
Description: A baseline of network operations and expected data flows for users and systems is established and managed
Component:
Control:
- AC-4
- CA-3
- CM-2
- SI-4
-
Category: DE.AE
Subcategory: 2
Description: Detected events are analyzed to understand attack targets and methods
Component:
Control:
- AU-6
- CA-7
- IR-4
- SI-4
-
Category: DE.AE
Subcategory: 3
Description: Event data are aggregated and correlated from multiple sources and sensors
Component:
Control:
- AU-6
- CA-7
- IR-4
- IR-5
- IR-8
- SI-4
-
Category: DE.AE
Subcategory: 4
Description: Impact of events is determined
Component:
Control:
- CP-2
- IR-4
- RA-3
- SI -4
-
Category: DE.AE
Subcategory: 5
Description: Incident alert thresholds are established
Component:
Control:
- IR-4
- IR-5
- IR-8
-
Category: DE.CM
Subcategory: 1
Description: The network is monitored to detect potential cybersecurity events
Component:
Control:
- AC-2
- AU-12
- CA-7
- CM-3
- SC-5
- SC-7
- SI-4
-
Category: DE.CM
Subcategory: 2
Description: The physical environment is monitored to detect potential cybersecurity events
Component:
Control:
- CA-7
- PE-3
- PE-6
- PE-20
-
Category: DE.CM
Subcategory: 3
Description: Personnel activity is monitored to detect potential cybersecurity events
Component:
Control:
- AC-2
- AU-12
- AU-13
- CA-7
- CM-10
- CM-11
-
Category: DE.CM
Subcategory: 4
Description: Malicious code is detected
Component:
Control:
- SI-3
-
Category: DE.CM
Subcategory: 5
Description: Unauthorized mobile code is detected
Component:
Control:
- SC-18
- SI-4
- SC-44
-
Category: DE.CM
Subcategory: 6
Description: External service provider activity is monitored to detect potential cybersecurity events
Component:
Control:
- CA-7
- PS-7
- SA-4
- SA-9
- SI-4
-
Category: DE.CM
Subcategory: 7
Description: Monitoring for unauthorized personnel, connections, devices, and software is performed
Component:
Control:
- AU-12
- CA-7
- CM-3
- CM-8
- PE-3
- PE-6
- PE-20
- SI-4
-
Category: DE.CM
Subcategory: 8
Description: Vulnerability scans are performed
Component:
Control:
- RA-5
-
Category: DE.DP
Subcategory: 1
Description: Roles and responsibilities for detection are well defined to ensure accountability
Component:
Control:
- CA-2
- CA-7
- PM-14
-
Category: DE.DP
Subcategory: 2
Description: Detection activities comply with all applicable requirements
Component:
Control:
- CA-2
- CA-7
- PM-14
- SI-4
-
Category: DE.DP
Subcategory: 3
Description: Detection processes are tested
Component:
Control:
- CA-2
- CA-7
- PE-3
- PM-14
- SI-3
- SI-4
-
Category: DE.DP
Subcategory: 4
Description: Event detection information is communicated to appropriate parties
Component:
Control:
- AU-6
- CA-2
- CA-7
- RA-5
- SI-4
-
Category: DE.DP
Subcategory: 5
Description: Detection processes are continuously improved
Component:
Control:
- CA-2
- CA-7
- PL-2
- RA-5
- SI-4
- PM-14
-
Category: RS.RP
Subcategory: 1
Description: Response plan is executed during or after an event
Component:
Control:
- CP-2
- CP-10
- IR-4
- IR-8
-
Category: RS.CO
Subcategory: 1
Description: Personnel know their roles and order of operations when a response is needed
Component:
Control:
- CP-2
- CP-3
- IR-3
- IR-8
-
Category: RS.CO
Subcategory: 2
Description: Events are reported consistent with established criteria
Component:
Control:
- AU-6
- IR-6
- IR-8
-
Category: RS.CO
Subcategory: 3
Description: Information is shared consistent with response plans
Component:
Control:
- CA-2
- CA-7
- CP-2
- IR-4
- IR-8
- PE-6
- RA-5
- SI-4
-
Category: RS.CO
Subcategory: 4
Description: Coordination with stakeholders occurs consistent with response plans
Component:
Control:
- CP-2
- IR-4
- IR-8
-
Category: RS.CO
Subcategory: 5
Description: Voluntary information sharing occurs with external stakeholders to achieve broader cybersecurity situational awareness
Component:
Control:
- PM-15
- SI-5
-
Category: RS.AN
Subcategory: 1
Description: Notifications from detection systems are investigated
Component:
Control:
- AU-6
- CA-7
- IR-4
- IR-5
- PE-6
- SI-4
-
Category: RS.AN
Subcategory: 2
Description: The impact of the incident is understood
Component:
Control:
- CP-2
- IR-4
-
Category: RS.AN
Subcategory: 3
Description: Forensics are performed
Component:
Control:
- AU-7
- IR-4
-
Category: RS.AN
Subcategory: 4
Description: Incidents are categorized consistent with response plans
Component:
Control:
- CP-2
- IR-4
- IR-5
- IR-8
-
Category: RS.MI
Subcategory: 1
Description: Incidents are contained
Component:
Control:
- IR-4
-
Category: RS.MI
Subcategory: 2
Description: Incidents are mitigated
Component:
Control:
- IR-4
-
Category: RS.MI
Subcategory: 3
Description: Newly identified vulnerabilities are mitigated or documented as accepted risks
Component:
Control:
- CA-7
- RA-3
- RA-5
-
Category: RS.IM
Subcategory: 1
Description: Response plans incorporate lessons learned
Component:
Control:
- CP-2
- IR-4
- IR-8
-
Category: RS.IM
Subcategory: 2
Description: Response strategies are updated
Component:
Control:
- CP-2
- IR-4
- IR-8
-
Category: RC.RP
Subcategory: 1
Description: Recovery plan is executed during or after an event
Component:
Control:
- CP-10
- IR-4
- IR-8
-
Category: RC.IM
Subcategory: 1
Description: Recovery plans incorporate lessons learned
Component:
Control:
- CP-2
- IR-4
- IR-8
-
Category: RC.IM
Subcategory: 2
Description: Recovery strategies are updated
Component:
Control:
- CP-2
- IR-4
- IR-8
-
Category: RC.CO
Subcategory: 3
Description: Recovery activities are communicated to internal stakeholders and executive and management teams
Component:
Control:
- CP-2
- IR-4
CRMs are provided by those IaaS/PaaS/SaaS providers that have already completed their system security documentation (usually FEDRAMP if you ever get to see it - or when inheriting from an agency run platform within an agency). They are basically the output of "we did all these things for this control, here is what you still have to do to fully implement this control".
OpenControl provides the ability to layer/combine multiple independent components (i.e. platforms/services/applications) together to create a complete system
this is done through the concept of inheritance. So is the best approach to:
certification
or standard
- which would make it more straightforward to speak directly to those responsibilities over the control generally?Any thoughts on how to handle standard revisions? For example NIST-800-53 is currently at revision 4 with revision 5 on the way, and it looks like -171 will be revised every year.
On the one hand, an assertion that a control is satisfied ought in some way to indicate the effective revision; but on the other hand I'd prefer to avoid having to go through my entire SSP changing 'standard: NIST-800-171r1' to 'NIST-800-171r2' next year and every year thereafter. (And on the third hand, being new to this game I'm not sure what sort of changes to expect between revisions...)
use the current verification
key in opencontrol format with id for (examples):
with a common:
schema to provide a common framework similar to test-kitchen - http://kitchen.ci/ verifier schema to provide a standardized means of validating a control
What is the appropriate way to document NIST 800-53 sub-elements in the component.yaml's?
In the FISMA guidance, we have controls with sub-elements. For example: AC-2
In the FedRAMP word templates, these sub-elements are broken out into tables:
In code I can do something like this:
- control_key: AC-2
standard_key: NIST-800-53
covered_by: []
implimentation_status: none
narrative:
- text: |
(a) some answer A
(b) some answer for B
..... however, using fedramp-templater, these sub-elements do not get properly populated. Anyone tackle this yet?
Preparing to send out a post symposium email. Simple checklist.
In preparing to package OpenControl for Enterprise Linux, I need to set an installation path.
Not sure OpenControl content has been packaged for the enterprise yet, so not sure if install paths have been determined.
How does /usr/share/opencontrol/${VENDOR}
sound?
e.g.
/usr/share/opencontrol/RedHat/{product1 product2 productX}
/usr/share/opencontrol/Docker/{product1 productX}
For Project Boise (#28), we're looking for who is actively using the OpenControl schema, Compliance Masonry, or any of the other tools under the OpenControl umbrella, and how they are being used. We are going to use this information to make the case for GSA renewing focus (and $$) on OpenControl, so it's important we hear from you.
If you're using it
If you're not using it, but are interested in doing so
Feel free to respond here, or email me directly at [email protected]. Happy to keep your answers private, if you like - being able to say "it's in use at X number of agencies" is useful on its own. Please respond by 9/13. Thanks!
https://github.com/18F/GSA-Certifications/blob/master/LATO.yaml
I've seen this referenced a few places with no context. What is it? The repo doesn't provide any references or information (I can open an issue there if necessary).
@mogul @joshuamckenty @gregelin and others have brought up the idea of having an in-person get-together (in San Francisco?) in the fall to sync up about OpenControl. Starting this discussion to figure out the things that need figuring out. Will continue adding to this list.
At Red Hat we've quietly been using ComplianceMasonry to generate SSP packages for FISMA baselines. We're going to open source our work, and I'm trying to find a home for upstream collaboration.
Is there an intent for OpenControl to host technology-specific content? For example, github.com/opencontrol/{rhel7 ubuntu-lts}?
(bump to @gregelin, as we spoke on this at RSA)
We are group of technologists, government staff, contractors and others in regulated fields passionately pursuing Compliance-as-Code.
We are developing a cmmunity and tools at http://open-control.org necessary to align security assessments and authorizations with modern, continuous software development and delivery.
We extend to you an invitation to join our Slack provided you agree to the following terms.
At all times you will engage in conversations that are respectful of other Slack members -- and third parties -- and professional in tone. We are professionals pursing professional goals. Respect and professionalism includes civil conversation, allowing others opinions, and avoiding personal disparaging comments, and contributing usefully to the community topic: Compliance-as-Code.
Always respect a designated moderator.
No matter how many TIE fighters are at your back, stay on the target topic of each channel.
Be biased toward conversation and participation. Be comfortable asking questions and providing answers.
It's fine to let others in the community know about professional events, positions, new software releases and other developments that are highly relevant to the OpenControl and Compliance-as-Code community.
It's also cool to share and celebrate accomplishments and support for community members in their achievement of some milestone, life-event, or other leveling-up. (It's also OK to professionally rally the community in support of community members.)
It is not fine to spam channels with multiple announcements, multiple times each week.
Promotions for things not related OpenControl and Compliance-as-Code is restricted to appropriately designated channels.
This policy is a "living" document, and subject to refinement and expansion in the future.
The OpenControl Slack is fine place for everybody regardless of race, religion, gender, identity, sexual orientation, technical ability, or employment situation.
If you are experiencing technical problems or non technical problems (like harassment) contact Greg Elin (@gregelin) or another moderator.
We have a number of repositories with different (or no) license files, and should probably decide on one...or at least a default. At 18F, we use CC0 with an explanation at the top:
https://github.com/18F/open-source-policy/blob/master/LICENSE.md
Would be simplest for the 18F staff to go with CC0 for consistency on our side (since our contributions are public domain), but not sure if we want to pick something that addresses patents.
Thoughts?
I mentioned to many in the OpenControl community that I submitted a session to OpenStack Sydney about OpenControl, and asked for help voting up the session.
Wanted to say thank you to everyone who voted the session up -- and with HUGE excitement wanted to share that the session was selected!!
Pretty interesting how the broader commercial and international community is interested in how to use OpenControl to help with ATO paperwork generation.
So really, thank you! Nothing like the pressure of a conference talk to expedite the OpenControl pieces shipping in RHEL/EPEL :)
I understand that use of opencontrol/masonry has not kept pace with the real-world demands for Word document output that can be consumed by assessors and auditors. In the case of cloud.gov compliance, would you be able to share an example Word document that is acceptable to assessors and auditors so I can see where gaps are?
https://github.com/opencontrol/cf-compliance-DEPRECATED was deprecated three years ago. Time to remove it?
Not sure where this information should live, but we should put information about contributing (as a "maintainer" or otherwise) somewhere. Things like:
Do I need to do anything special if my opencontrol.yaml references a variety of system dependencies and the dependencies component.yaml's are a mixture schema versions?
Let's use this issue to capture other events, conferences, workshops, camps of interest to us and Compliance-as-Code. Perhaps we should try to have OpenControl presence?
The https://github.com/opencontrol/PCI-DSS-Standards hasn't been touched for a few years, and the PCI-DSS content was incorporated into https://github.com/opencontrol/standards.
As a little spring cleaning, should the https://github.com/opencontrol/PCI-DSS-Standards repo be removed? Would it make sense to create an updated README for a little while?
(IMHO an updated readme is not needed, since the opencontrol/standards project has included PCI-DSS for at least 6mo)
Would be great to also format the DOD 8500.2 control list against the OpenControl schema
The current schema supports implementation_status
, taken literately this means it can generate your still-need-to-do list otherwise known as the A Plan of Action and Milestones (POA&M)
.
It makes sense to use implementation_status
other than complete
to generate a csv file that could serve as a crude POA&M spreedsheet.
The OpenControl slack community is now live at https://opencontrol.slack.com
There is a self-inviter here: https://opencontrol-slack-inviter.herokuapp.com
This issue is to discuss migrating the communications from 18F slack channel.
Per discussion in opencontrol/schemas#61 ... we need to figure out a way to allow one to reference specific versions of a component file. A simple solution would be to create separate component.yml
files for each version of the component and reference them accordingly in opencontrolyml
. However, this breaks when one imports component controls from a Git repo rather than a local path.
@gregelin proposed a package management solution, but this could be more work than it's worth. Thoughts on this?
A question for federal contractors performing digital services/IT Modernization work for the Government: The ATO process at the end of development is an inevitable hurdle to overcome for successful project completion. What could help the contractor or project team achieve a smoother ATO?
Do you see any benefit in including the government contractor in the ATO process? Perhaps including NIST standards in RFQs? Or having them create the Compliance Masonry as part of a contract requirement?
I'm a GSA Contracting Officer hoping the better the process for the entire project team (contractor and Government). Thank you!
I've created a Save the Date email in MailChimp that I hope to send out tonight. Here it is:
10/20/2016
Open Control Gathering/Symposium
Thanks for your interest in an OpenControl live event!
Thursday, October 20, 2016, in Washington, DC
seems the best date and location with enough time to promote
We are group of technologists, government staff, contractors and others in regulated fields committed to Compliance-as-Code. We are developing tools necessary to align security assessments and authorizations with modern, continuous software development and delivery.
We want to build the OpenControl community (http://open-control.org) via a symposium or other social gathering this fall.
http://bit.ly/ocsymp-googlecal • http://bit.ly/ocsymp-ical
About OpenControl
Community, data, and tools for Compliance-as-Code
Web: http://open-control.org
Github: https://github.com/opencontrol
Slack: https://opencontrol.slack.com
Webinars: http://bit.ly/opencontrol-webinars
Our mailing address is:
OpenControl
2011 Crystal Drive
Suite 400
Arlington, VA 22202
(various unsubscribe information)
...especially those without a ton of compliance experience. I've spoken with multiple software vendors in that boat who are interested in using OpenControl, but aren't sure about where to start. Would be good to include some of the following:
This would likely look a lot like Compliance Masonry for the Compliance Literate, but with an audience of Not Compliance Literate Vendors. Not sure where said resource should live.
It would be useful to have a more comprehensive list of use cases for OpenControl data specification.
On this page:
https://github.com/opencontrol/compliance-masonry/blob/master/docs/masonry-for-the-compliance-literate.md
In the second to last paragraph, there is the sentence:
"Compliance Masonry templates can run executable specifications which are used to continuously monitor that systems behave in the way they’re documented."
I went looking for this functionality and I couldn't find anything anywhere about it (other than this statement) in the documentation. Has this been implemented? I apologize if it is there and I just missed it.
It's difficult for me to determine if the opencontrol framework supports the concept of overlays. An example overlay is the Privacy overlay from CNSSI 1253 Appendix F. There are other example overlays on https://www.cnss.gov/CNSS/issuances/Instructions.cfm.
From https://www.nist.gov/services-resources/software/baseline-tailor overlays are used in tailoring controls for different types of systems.
There is some nuance in overlays in that multiple can be applied to a system with conflicting customization.
I'm considering pre-processing tools that generate a standard for usage with the opencontrol framework.
Does opencontrol support the concept of overlays or tailoring without adjusting the standard?
Looks like Chef came out with a pretty slick open source compliance-as-code framework and DSL called InSpec (http://inspec.io/) which supports a number of OS's. This could be a nice complement to OpenControl in the form of BDD testing. Some ideas below:
component.yaml
definitionsIt would be great to come up with a consensus on where OpenControl fits in to the actual generation of documentation. There have been some discussions on Slack in regards to removing the actual SSP documentation generation functionality from compliance-masonry, and instead use it solely for validation, gap analysis and converting yaml to various meta-formatted text (e.g. markdown and ReStructuredText which can be fed in to MkDocs, Jekyll, Readthedocs, etc). Do folks agree on this approach?
I’m going to be in DC for Project Boise (#28) meetings - let’s do an OpenControl get-together! Monday 7/31 at Elephant & Castle at 900 19th Street at 5:30pm. All are welcome.
Hi folks!
Wanted to send you an update about what's happening at 18F. We have started an initiative with the (arbitrary) working title "Project Boise", whose goal is to "reduce the burden (time, cost, and pain) and improve the effectiveness of the federal government’s software security compliance processes." This is, we hope, very much in line with OpenControl, though may extend more broadly (to things like policy). Take a look at our project overview (https://boise.18f.gov) - would love your feedback! Feel free to leave comments here, shoot me an email, etc.
In our “Discovery” phase, we’re looking to talk to folks in the following areas:
If you fall into one of those categories, or have a connection with someone who does, please get in touch.
Thanks!
Aidan Feldman
[email protected]
Great work on this tool! Last week, a colleague discovered, that the SSP PDFs that are produced by Compliance Masonry do not include the NIST Control statements; just the implementation statements of the respective controls. This could prove rather cumbersome for our assessors. Is there way to include the NIST control statements for each control, right before the implementation statements? I couldn’t find an easy way of doing that.
The OpenControl project is no longer only 18F and hasn't been for some time (which is great!!). To reflect this, suggesting the OpenControl org permissions be restructured.
Currently there are four organizational teams (https://github.com/orgs/opencontrol/teams):
Suggest the following:
Creation of net-new community-members
team. Members would be able to be own tickets, be tagged in PRs, etc. Need a vehicle to recognize community participants and communicate with them.
Creation of repository maintainer teams, such as certification-maintainers
, compliance-masonry-maintainers
, etc. Members would have write-access to those repos. Currently it's to hard to track permissions and no clear way to give them out either. Also means interested parties could @repo-maintainers
when asking for help, a quick PR review, etc.
In component.yaml, we define controls. Each control has a 'standard_key' and a 'control_key' and (among other things) a 'narrative' section.
Is it possible to have one component control definition to implement multiple standards' controls so that one narrative section could be used to satisfy the control requirements for multiple standards? Or one control that implements multiple required controls w/in one standard.
I've tried putting in multiple 'standard_key' and 'control_key' sections and that doesn't appear to work, I only get one section in the output document.
In order to make the process of targeting the correct and complete list of controls easier to understand for new users/components. Open Control should provide a cheatsheet/guide on some general types of SecOps tooling and to which controls they'd typically contribute to.
In order to effectively do this there needs to be an established taxonomy of component types. Based on some looking into one ready made framework could be the NIST Framework for Improving Critical Infrastructure Cybersecurity https://www.nist.gov/cyberframework. I went ahead an converted the spreadsheet into 3 yaml chunks for the Function -> Category -> Subcategory
hierarchy:
https://gist.github.com/JJediny/65438415b5e38ac7560ad5f5597f1877
But that only serves as topic areas not discrete categories by which to curate a group of related/similar technologies that ideally share a common mapping to controls.
https://cloudsecurityalliance.org/wp-content/uploads/2011/09/SecaaS_V1_0.pdf
https://downloads.cloudsecurityalliance.org/assets/research/security-as-a-service/csa-categories-securities-prep.pdf
https://cloudsecurityalliance.org/group/security-as-a-service/#_downloads
Has anyone imported the AICPA TSC for SOC2 into the standard
format ala opencontrol/standards/blob/master/pci-dss.yaml?
About to start on that task soon, collaborators welcome.
In the current RedHat content repo, directory structure is used to breakout products:
https://github.com/opencontrol/RedHat/tree/master/OpenShift-v3
https://github.com/opencontrol/RedHat/tree/master/OpenStackPlatform
edit: Not sayin' this is the best practice or most ideal, just how we got started :)
If I understand the OpenControl schema for systems
correctly, only url
and revision
can be passed as arguments:
https://github.com/opencontrol/schemas/blob/master/kwalify/opencontrol/v1.0.0.yaml#L53#L61
systems:
type: seq
sequence:
- type: map
mapping:
url:
type: str
revision:
type: str
This forces us to create many content repos, e.g. redhat-rhel, redhat-openshift, redhat-jboss, instead of one per vendor.
Has there been a discussion on if this is desired? Should we update the schema to support a directory tree, e.g.:
systems:
- url: https://github.com/opencontrol/RedHat
revision: master
folder: tree/master/Product1
- url: https://github.com/opencontrol/RedHat
revision: master
folder: tree/master/Product2
I have two clients each with an ATO and tus an SSP. It's reasonably straightforward to pull each family of controls into separate .md files in GitHub (well, I'm using GitLab now). The next step is to convert the controls into OC YAML Components, but this is not 1:1. Does a suggested mapping exist?
I understand that each site will have its differences, but there is likely to be a fair amount of commonality. If the process can be reduced to a script that handles 90% of the controls and a process for massaging the 20% that didn't "fit" correctly, I believe this may help facilitate adoption.
From the email:
[Company] has clients (or potentially has client) that would like to leverage opencontrol and compliance-masonry to speed up the ATO process. An example implementation might be running CF in AWS, and some apps on top of that. So one thing I'm working on is a HelloWorld-type app that demonstrates a complete SSP built up from various components.
The schema and tooling are great, but there are gaps more than a few areas of confusion. Before I dive in too deep on the schema or the Go code I should probably find out more where y'all are heading so we're not working at cross purposes.
Also of interest is the goal, per @NoahKunin, of "creating data structures that enable us to create continuous monitoring platforms". Some of the BDD examples are interesting, and I'd like to build on that with InSpec profiles that run against nodes or even the entire platform with inspec-aws. I'm also interested in how, potentially, Nessus scans are created and run as part of a pipeline.
So, that's what I'm up to. Are there any sources of information I should be tracking besides the repos and issues for opencontrol/compliance-masonry and opencontrol/schemas? I see that identity-idp has security committed in-place. Are there other examples that you'd recommend where this is happening?
A few questions in no particular order:
Are there any YAML files of the three types of security compliance codes?
Consider tools like Gemnasium, Quantified Code, and Travis -- each covers some component of the compliance process. However, adding a verification for each requires adding a unique URL (i.e. pointing to the project page within Gemnasium, QC, Travis). It'd be handy if we could define component docs for each of these tools once and re-use them across projects, but there's no way to template that URL/project id/etc. One potential approach would be to add something to the opencontrol.yaml
file:
dependencies:
systems:
- url: https://path/to/travis/docs
parameters:
badge: https://travis.thing/image/myproject
In order to enable broad collaboration on OpenControl among parties with overlapping (but potentially misaligned) interests in a common roadmap, we should come up with a lightweight governance process and a cadence for regularly meeting to update and surface concerns related to the roadmap.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.