Check Out Our - Security & GRC Decoded Podcast
ComplianceCow

Documentation

Contents

ComplianceCow automates controls testing for Security Compliance for applications running on cloud and kubernetes. If you are a first time user, please do a quick read on the ComplianceCow integration workflow below. If you already know or have no patience to read through :), please skip to the Get Started section.

You can integrate your applications seamlessly with ComplianceCow, for your team-mates to perform the below:

  • Create application scopes against available assessments.
  • Run the assessments for the specified application scope and other inputs.
  • Post the run, collaborate with team members and operate the assessment run controls to add/update evidences, checklists, notes and attachments.
  • View Reports

Setup and Run an assessment

The following sequence diagram explains the application scope/setup and the execution steps to run in detail.
Doc 1.1
Creating an application scope
The Application scope flow specifies the services/applications that the user integrates with, in order to evaluate the security posture, collect evidences and report. The Application scope flow can vary dependent on the assessment selected (more about the assessment below) User creates an application scope in ComplianceCow with required credentials. A few examples below:
  • Azure: Azure Subscriptions Client ID, Client Secret and the Subscription ID.
  • Azure Kubernetes Services: In addition to the subscriptions, the user can specify one or more clusters: private or public. The user will need to provide access to a kubectl instance (VM) that has access to the private or public cluster
Note: ComplianceCow will auto discover services for Azure and Kubernetes. For Azure, ComplianceCow will determine Resource Groups, Virtual Networks and Subnets. Specifically for AKS, the system will automatically enumerate all the namespaces for the selected cluster. The user can specify the scope by selecting one or more of these elements such as Resource Groups, VNETs, Clusters; as applicable
Executing an Assessment
An Assessment, in this context, is a collection of security controls such as PCI-DSS, CIS Benchmark, etc. It is made up of the hierarchical set of controls. Each control can be automated; i.e, automatically collects evidences from the underlying services such as Azure and/or AKS services or can be manual. In order to execute an assessment, the user
  • Selects an application scope
  • Enters the control duration or sampling period
  • Provides run time user inputs, if any
This adds a ticket to the execution queue and the ComplianceCow system automatically connects with the services in the application scope to collect data, evidences and testing results.

Operate an Assessment

The following describes the hierarchical structure of an assessment run:
doc-2.1

Evidence

There can be one or more evidences. These evidences can be automated or manual. When ComplianceCow automatically fetches evidences from Azure or AKS services, they go here. The user can also manually upload evidence files. An evidence file in ComplianceCow has 3 components:
  • Data file: This file contains the data generated in a common data model from the services. For example, there is a file for all entries in Network Security Group for the selected scope in azure subscriptions. This file is typically in parquet format in ComplianceCow.
  • Meta file: This file is an index file that contains all the metadata for the rows in the corresponding data file. For example, the meta file may contain a record that indicates the status of a record. If a row is deleted in the data file, ComplianceCow does not change the data file but instead maintains a marker in the meta file.
  • Column file: This file contains the metadata information for each field in the data file. For example, it holds the data type of columns in the data file All files; Data, Meta and Column are versioned controlled for each commit in ComplianceCow. Any save of these files are saved on to the user workspace and are not moved to the version control system until the commits happen.
The following sequence diagram explains the Post Run Workflow and Reports in detail.
doc-3.1

Post Run Workflow

Each Control, Subcontrol, Checklist, Evidence can be assigned to one or more users. ComplianceCow follows a git checkout type of model for workflows. All assigned users will see the assignment upon logging in, however when any one user checks-out, s/he owns the element (control, evidence, checklist etc.) and will disappear from the work queue of other users. When an assessment is run, it is called an Assessment Run Instance or just an Assessment Run. Each Assessment Run is a unique copy of the Assessment for the selected application scope with Evidences, Checklists, Notes etc.

Reports

ComplianceCow allows a flexible reporting mechanism. Reporting in ComplianceCow is organized along the following:
doc-4.1

Report is the atomic unit of work that can either return data or a visual object. The data can be specified in multiple formats. A Dashboard is a collection of one or more reports. Each Dashboard is categorized under Category (needless repetition!!) and the categories are nested inside Assessment. The Dashboards and the Reports can be for a specific Assessment Run or across multiple Assessment Runs or even can span over multiple Assessments.

ComplianceCow Chat Applications

Chat allows us, ComplianceCow, to reduce friction and to increase productivity for our partners and customers. We currently support the following mediums: Slack, Microsoft Teams and Skype.
Some of the key operations that you can perform using our bot
  • Onboard and Register through self-service
  • Manage users
  • Configure Assessment Controls
    • Create Assessment Templates
    • Execute Assessments – Automated or Manual
  • Manage Assessment Workflow
    • Evidence Records
    • Notes
    • Checklist
    • Attachments
  • View Reports
Please Click here to download the user manual. You can also Contact Support.

Get Started

You have two modes through which you can integrate your application(s) with ComplianceCow.
  • API (REST)
  • SDK (Limited to Python and Reports, for now)
In other words, each step mentioned in the sequence diagrams (above) can be accomplished by either calling an API or invoking an SDK method.
REST API
We have a Swagger put up for you to test the various APIs, which would need to you authorize yourself via any of the OAuth2 social login options. Link to the swagger can be found here.
SDK
The SDK is limited to a data library which exposes all of the ComplianceCow data and metadata so that our customers and users can build models, create custom reports or simply use them as signals to enrich security posture. We are also publishing a sample notebook that has the methods used in the data library for consuming data, metadata and reports. The SDK (available in Python for now) can be downloaded from GitHub, which has a README file too.