Merge pull request #16 from dcomas/main

add security assurance section

content/incident-response.md

@@ -23,9 +23,3 @@ Sysdig Secure 3.0 https://sysdig.com/blog/sysdig-secure-3-0/
 Rapid7 (InsightIDR, DivvyCloud kAudit)
 Trend Micro Workload Security (https://www.trendmicro.com/en_ca/business/products/hybrid-cloud/cloud-one-workload-security.html)
 -->
-
-## Examples
-- TODO
-
-## Links (optional)
-- TODO

content/index

@@ -43,7 +43,7 @@
     - { "name": "Identity and Access Management", "slug": "identity-and-access-management"}
     - { "name": "Credential Management (Hardware Security Modules (HSM) + Credential Management Cycle)", "slug": "credential-management"}
     - { "name": "Availability (Denial of Service (DoS) & Distributed Denial of Service (DDoS))", "slug": "availability"}
-- { "name": "[UNDER CONSTRUCTION] Security Assurance", "slug": "security-assurance"}
+- { "name": "Security Assurance", "slug": "security-assurance"}
   - { "name": "Threat Modelling", "slug": "threat-modelling"}
   - { "name": "Threat Intelligence", "slug": "threat-intelligence"}
   - { "name": "Incident Response", "slug": "incident-response"}

content/least-privilege.md

@@ -0,0 +1,42 @@
+---
+title: "Least Privilege"
+date: "2020-10-01"
+category: "Security Assurance"
+---
+
+Least privilege is just as important, or perhaps the most important aspect of cloud native architectures, and must be considered at all parts of the stack where an authentication or authorization decision is made. Traditionally Least Privilege has been thought of at the account layer whether that account is a human or a service.
+
+In cloud native, least privilege must be applied at every layer of the stack. It should also be considered when evaluating the specific tooling responsible for fulfilling each layer's execution. Organizations may find, as they explore various products and capabilities, that many containers have privileged-by-default deployments or required root privileges to operate. As a result, additional measures may need to be taken to isolate those elevated privileges from the rest of the workload. Organizations should consider all areas to employ isolation and least privilege in their workloads and deployments; from cgroups and system calls in the runtime environment to artifact management and rootless builds.
+
+To consistently reduce the potential attack surface and corresponding blast radius, organizations need to implement the principle of least privilege at every level of their architecture. This not only applies to the individuals performing various functions within their roles but also to the services and workloads executing in a given environment. Rootless services and containers are vital to ensuring that if an attacker does get into an organization's environment, they cannot easily traverse between the container they gain access to and the underlying host or containers on other hosts.
+
+Mandatory Access Control (MAC) implementations (e.g. SELinux and AppArmor) can limit the privileges beyond those set to the container or namespace and provide additional container isolation at the host level to prevent container breakout or pivoting from one container to another to escalate privileges beyond those permitted by the access control in place.
+
+## Projects
+- [OPA](https://github.com/open-policy-agent/opa)
+- [Kyverno](https://github.com/kyverno/kyverno)
+- [Keycloak](https://github.com/keycloak/keycloak)
+
+
+<!--
+Commercial Projects (optional)
+Styra DAS (styra.com)
+Nirmata (nirmata.com)
+Build Security (build.security)
+
+-->
+
+## Examples
+- Only on-call engineers should be allowed access to servers
+- Users with a particular role (and other attributes) should be allowed to perform certain actions on a certain resource
+- Individual users can be granted temporary elevated permissions (e.g. API gateway plus multi-factor authentication solution, such as Keycloak) so that elevated permissions are not only time (and scope) limited, but additional MFA requirements (such as a human being manually approving the request under specific conditions) help to minimize attacks, and avoid the individual having un-needed permissions/privileges around-the-clock.
+- Individual applications can adopt this principle via the use of capabilities on Linux-based systems (kernel v2.2 and onward) to voluntarily relinquish the ability to execute certain operations when the application has no further need for said operations.
+- In Kubernetes, RBAC “Role” objects can be used to restrict “apiGroups”, “resources”, and “verbs”, so that applications can be configured at the pod level to have limited capabilities with respect to interacting with the Kubernetes API, API server, and other resources within the cluster.
+- Individual containers can be denied access to privileged operations (i.e. “docker run … --privileged) to limit capabilities and reduce the attack surface with respect to privilege escalation.
+- Inherent Kubernetes features such as SubjectAccessReview can be utilized to generate unit tests to verify if a pod has the necessary authorization to execute specific operations. The tests can then be used by QA teams to prune roles/abilities to the minimum required for normal operation.
+
+## Other Links/Materials:
+- [capabilities(7) - Linux Manual Page](https://man7.org/linux/man-pages/man7/capabilities.7.html)
+- [“Using RBAC Authentication”](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
+- [“Authorization Overview”](https://kubernetes.io/docs/reference/access-authn-authz/authorization/)
+

content/roles-and-responsibilities.md

@@ -1,7 +1,7 @@
 ---
 title: "Roles and Responsibilities"
 date: "2020-10-01"
-category: "develop"
+category: "Security Assurance"
 ---
 
 When moving to cloud native architectures and deployments, organizations should expect to see adjustments in legacy security roles and responsibilities and create new security roles specific to the cloud. With the rapid onset of modern development methodologies and better alignment of IT activities with business needs, security must be adaptive, commensurately applied with actual risk, and transparent. It is unreasonable to expect developers and operations to become security experts. Security practitioners need to partner with developers, operations, and other project life elements to make security and compliance enforcement fully integrated with process modernization efforts and development lifecycles. Doing so means findings are reported in real-time through the tools in use by developers for habitual resolution, akin to how build failures are resolved at notice.
@@ -11,10 +11,38 @@ The blurred lines that often occur in DevOps environments should not replace cle
 Organizations will need to reevaluate their asset risks as products and services migrate to the cloud. With ownership and management changes of the technology in use and its deployment stack, executives should expect significant risk posture changes. Shared responsibility between providers and teams will require changes to thresholds in risk acceptance, transference, and new mechanisms for mitigation.
 
 ## Projects
-- TODO
+- [Kubernetes Annotations examples include responsible owner](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/#attaching-metadata-to-objects)
+- Segregation of Duties (aka Separation of Duties) 
+  - K8s RBAC (+ OPA rego for enforcing separation?)
+    - https://github.com/FairwindsOps/rbac-manager
+    - https://github.com/corneliusweig/rakkess
+    - https://github.com/FairwindsOps/rbac-lookup
+CI/CD pipeline review checkpoints enforced
+- [Kyverno](https://github.com/kyverno/)
+- [Some examples of role names adapted from/aligned with NIST OSCAL:](https://pages.nist.gov/OSCAL/documentation/schema/implementation-layer/ssp/xml-schema/#global_responsible-role)
+  - See https://github.com/cncf/sig-security/issues/423
+- The NIST CSF has five specific security related functions/responsibilities that could be mapped to specific roles: 1) identify, 2) protect, 3) detect, 4) respond and 5) recover.
+
+<!--
+Commercial Projects:
+AWS IAM Analyzer/Zelkova (https://aws.amazon.com/blogs/security/how-to-automatically-archive-expected-iam-access-analyzer-findings/)
+Google Cloud Recommender (https://cloud.google.com/iam/docs/recommender-overview)
+AWS SoD - AWS services that help implement/enforce SoD (shamelessly plagiarized from https://stelligent.com/2018/10/30/segregation-of-duties-on-aws/)
+AWS CloudTrail – across all regions with log file integrity validation (to ensure nonrepudiation)
+CloudWatch Monitoring, Events and Alerts – Receive notifications and respond to events
+CloudWatch Logs – Log all changes to all relevant services. Store logs in S3 and apply least privilege IAM and S3 bucket policies for access
+AWS CodePipeline – orchestrate the deployment pipeline automation
+AWS Config and Config Rules – use managed and custom config rules to perform actions and/or get notified when services make modifications that violate corporate policies
+Encryption – There are many AWS services that provide encryption at rest and in transit that help prevent changes and data exfiltration. For encrypting data at rest, these include using the AWS Key Management Service (KMS) with CloudTrail, DynamoDB, EBS, RDS, and S3 – to name a few. For data in transit, using ACM with ELB for applications.
+AWS Identity and Access Management (IAM) – Ensure least privilege for all AWS resources.
+Amazon Macie – to proactively monitor sensitive data (e.g. PII) entering the system
+AWS Service Catalog – to enforce policies while maintaining autonomy
+-->
 
 ## Examples
-- TODO
+- AICPA (SOC2): “The principle of SOD is based on shared responsibilities of a key process that disperses the critical functions of that process to more than one person or department. Without this separation in key processes, fraud and error risks are far less manageable.”
+- [Kubernetes RBAC and SoD](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#api-authorization)
+
 
-## Links (optional)
-- TODO
+## Links
+- [Semantic RDF in policy](https://www.w3.org/RDF/)

content/threat-intelligence.md

@@ -0,0 +1,32 @@
+---
+title: "Threat Intelligence"
+date: "2020-10-01"
+category: "Security Assurance"
+---
+
+Cloud native applications by design and purpose are a collection of multiple dynamic components compromised from first-party and third-party code and tools, which means threat intelligence must be applied for network activity and cloud native application components. Cyber threat intelligence is information about threats and threat actors that helps mitigate harmful events. Threat intelligence in cloud native systems would make use of indicators observed on a network or host such as IP addresses, domain names, URLs, and file hashes which can be used to assist in the identification of threats. Behavioral indicators, such as threat actor tactics, techniques, and procedures can also be used to identify threat actor activity in cloud native components. The [MITRE ATT&CK framework for Cloud](https://attack.mitre.org/matrices/enterprise/cloud/) includes cloud native tactics and techniques that can be leveraged as a starting point for establishing and validating observability.
+
+## Projects
+- [MISP](https://www.misp-project.org/)
+- [Medallion - proof of concept](https://github.com/oasis-open/cti-taxii-server)
+- [OpenCTI](https://www.opencti.io)
+- [OSINT Framework](https://osintframework.com/)
+- [Threatcrowd](https://www.threatcrowd.org/)
+
+<!--
+Commercial Projects (optional)
+Limo (https://www.anomali.com/resources/limo)
+Rapid7 (www.alcide.io)
+Trend Micro Smart Protection Network (https://www.trendmicro.com/en_us/business/technologies/smart-protection-network.html)
+Aqua Vulnerability Database (https://avd.aquasec.com/)
+-->
+
+## Examples
+- Threat intelligence is the collection and application of indicators, behaviors, and attack information observed during cybersecurity incidents in order to detect threats in your environment.
+  - Primitive threat intelligence indicators are immutable values such as IP addresses, domains, and file hashes associated with known threats.
+  - Complex threat intelligence indicators are rules or logic that identify behaviors associated with known threats. Examples of complex indicators include yara rules, SIGMA rules, and suricata rules.
+- Tactics, Techniques and Procedures (TTPs) are behaviors, actions, and common methods used by threat actors to achieve an objective.
+
+## Other Links/Materials:
+[TAXII/STIX](https://oasis-open.github.io/cti-documentation/)
+[MITRE ATT&CK](https://attack.mitre.org/)

content/threat-modelling.md

@@ -1,7 +1,7 @@
 ---
 title: "Threat Modeling"
 date: "2020-10-01"
-category: "develop"
+category: "Security Assurance"
 ---
 
 For organizations adopting cloud native, the primary mechanism of identifying risk and resulting controls and mitigations is to perform threat modeling of applications, data flows, and supporting processes and infrastructure. The method by which this is accomplished is minimally different from typical threat modeling. The below guidance is an enhancement of the four step OWASP threat modeling recommended for cloud native capabilities.
@@ -34,10 +34,14 @@ The utilization of pipelines and infrastructure as code (IaC) may provide compen
 As with any cloud native process, it is important to iterate and provide feedback. In the context of threat modeling, this means re-evaluating if the existing measures, mechanisms, and matrices accurately reflect the operational state given the continual changes to the architecture.
 
 ## Projects
-- TODO
-
-## Examples
-- TODO
-
-## Links (optional)
-- TODO
+- [OWASP Threat Dragon](https://owasp.org/www-project-threat-dragon/)
+- [Microsoft Threat Modeling Tool](https://docs.microsoft.com/en-gb/azure/security/develop/threat-modeling-tool)
+- [Threatspec](https://github.com/threatspec/threatspec)
+
+## Other Links
+- [The Current State of Kubernetes Threat Modeling](https://www.marcolancini.it/2020/blog-kubernetes-threat-modelling/)
+- [Guidance on Kubernetes Threat Modelling](https://www.trendmicro.com/vinfo/us/security/news/virtualization-and-cloud/guidance-on-kubernetes-threat-modeling)
+- [Kubernetes Threat Model by Trail of Bits (June 2019)](https://github.com/kubernetes/community/blob/master/sig-security/security-audit-2019/findings/Kubernetes%20Threat%20Model.pdf)
+- [Risk8s Business: Risk Analysis of Kubernetes Cluster](https://tldrsec.com/guides/kubernetes/)
+- [Securing the 4 Cs of Cloud-Native Systems: Cloud, Cluster, Container, and Code](https://www.trendmicro.com/vinfo/us/security/news/virtualization-and-cloud/securing-the-4-cs-of-cloud-native-systems-cloud-cluster-container-and-code)
+- [K8s Threat Model](https://cloudsecdocs.com/container_security/theory/threats/k8s_threat_model/)