From 9def703280d05db1d9d6e38f285586cb66918718 Mon Sep 17 00:00:00 2001 From: Diego Comas Date: Wed, 21 Apr 2021 01:30:33 +0200 Subject: [PATCH 1/2] add Security Assurance section --- content/incident-response.md | 6 --- content/index | 2 +- content/least-privilege.md | 42 ++++++++++++++++++++ content/roles-and-responsibilities.md | 38 +++++++++++++++--- content/threat-intelligence.md | 32 +++++++++++++++ content/threat-modelling.md | 20 ++++++---- content/zero-trust-architecture.md | 56 +++++++++++++++++++++++++++ 7 files changed, 176 insertions(+), 20 deletions(-) create mode 100644 content/least-privilege.md create mode 100644 content/threat-intelligence.md create mode 100644 content/zero-trust-architecture.md diff --git a/content/incident-response.md b/content/incident-response.md index 2384027b8..31b388952 100644 --- a/content/incident-response.md +++ b/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 diff --git a/content/index b/content/index index fbafdbcab..bcc5a6985 100644 --- a/content/index +++ b/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"} diff --git a/content/least-privilege.md b/content/least-privilege.md new file mode 100644 index 000000000..b0a93d809 --- /dev/null +++ b/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) + + + + +## 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/) + diff --git a/content/roles-and-responsibilities.md b/content/roles-and-responsibilities.md index 6754779ce..66ef41974 100644 --- a/content/roles-and-responsibilities.md +++ b/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. + + ## 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/) diff --git a/content/threat-intelligence.md b/content/threat-intelligence.md new file mode 100644 index 000000000..2120c82e3 --- /dev/null +++ b/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/) + + + +## 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/) diff --git a/content/threat-modelling.md b/content/threat-modelling.md index d6b0cbc53..14b559089 100644 --- a/content/threat-modelling.md +++ b/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/) \ No newline at end of file diff --git a/content/zero-trust-architecture.md b/content/zero-trust-architecture.md new file mode 100644 index 000000000..2882547d4 --- /dev/null +++ b/content/zero-trust-architecture.md @@ -0,0 +1,56 @@ +--- +title: "Zero Trust Architecture" +date: "2020-10-01" +category: "Security Assurance" +--- + +Zero trust architectures mitigate the threats of lateral movement within a network through fine grained segmentation, micro-perimeters, and removing implicit trust to data, assets, applications, and services (DAAS) with verification and enforcement policies. Most common implementations of zero-trust architecture rely on cryptographic concepts to create zero trust. This is primarily based on the ability to have specific key material secured in hardware or tokens and managed in a way where they can be securely communicated to a platform. + +The foundational building block that zero trust architecture usually consists of several aspects: + +- Each entity can create proof of who the identity is +- Entities are able to independently authenticate other identities (i.e. Public Key Infrastructure) +- Communications between entities remain confidential and untampered +The zero trust framework creates the zero trust building blocks by leveraging a strong root of trust: the ability to tie a tamper-resistant trust to an entity or process is the foundational building block. It then requires attestations: the ability to attest, validate, and prove the identity of an entity. For the example of container services, how do I check that this container is who it claims to be. This needs to be verified with the orchestrator, but to trust the orchestrator, we need to ensure it is running untampered, which can only be ensured if we are running a trusted OS, BIOS, etc. Attestations are usually a chain as well. + +Zero trust also requires secure communication between entities. While network segmentation provides value to zero trust architectures and should be considered, is not an end all solution to zero trust implementation. Orchestrator network policies as well as use of a service mesh are all components of a comprehensive zero trust solution. More information on zero trust concepts is available widely online. + +## Projects +- [Project Calico](https://www.projectcalico.org/) +- [SPIFFE/SPIRE](https://github.com/spiffe) +- [OPA](https://github.com/open-policy-agent/opa) +- [Istio](https://github.com/istio/istio) +- [Linkerd](https://github.com/linkerd) +- [HyperLedger](https://www.hyperledger.org/) +- [HashiCorp Vault](https://github.com/hashicorp/vault) +- [Keylime](https://keylime.dev/) + + + +## Examples +- Enforced secure communication between nodes/endpoints independent of the pods/applications involved, either via service meshes, CNI-specific features, or other means (i.e. don’t trust individual applications to necessarily handle their own secure communications). Blob of text +- Protocols may be enhanced (e.g. additional endpoint verification, such as remote hardware attestation in addition to transport security), but never downgraded below the mandated baseline. +- Network policies (e.g. including the implementations already inherent to Kubernetes) can supplement additional tools/technologies via ingress and egress rules to explicitly define permitted connections between pods via rules and relationships. +- De-centralized identity management using technologies such as trust engines and threat scores can be used to handle authentication, and can be further supplemented via additional technologies (e.g. blockchain) to supplement trust-engine based means of user/device authentication. +- Dynamic secrets and routine certificate rotation can be handled via certificate management systems (e.g. HashiCorp Vault), along with revocation of compromised certificates. +- Remote hardware attestation (e.g. Keylime) can be used to verify the integrity of individual nodes (i.e. bootloader, kernel, PCR values, etc.), and related technologies (e.g. SecureBoot, measured boot) can potentially prevent compromised hosts from fully booting (preventing attempts to even join the private network). +- “Validating” admission controllers (e.g. OPA) can ensure individual applications (i.e. in the form of pods) meet specific security requirements before allowing the application to launch, while “mutating” admission controllers can modify the runtime parameters (e.g. environment variables, network ingress/egress policy, RBAC-related configuration, etc.) so that any/all applications executed in the cluster have been sanitized as per cluster security policy before any container code can be executed. “Init containers” can also be injected as an additional run-time prerequisite. +- Private PKI (e.g. via Vault) is preferred over public PKI, but public PKI is preferred over no PKI (Gilman, Barth). Certificate management solutions that are 100% controlled by the cluster owner are preferred over any alternatives. + + +## Other Links/Materials: +- [Project Calico Documentation: Adopt a zero trust network model for security](https://docs.projectcalico.org/security/adopt-zero-trust)Link 1 +- [Integrating Calico and Istio to Secure Zero-Trust Networks on Kubernetes](https://www.altoros.com/blog/integrating-calico-and-istio-to-secure-zero-trust-networks-on-kubernetes/) +- [Istio Security: Zero-Trust Networking](https://blog.aquasec.com/istio-kubernetes-security-zero-trust-networking) +- [Docker Con 19 - “Zero Trust Networks Come to Enterprise Kubernetes” slides](https://www.slideshare.net/Docker/dcsf-19-zero-trust-networks-come-to-enterprise-kubernetes) +- [Zero Trust Networks (Gilman & Barth 2017)]() + From fa6c9049e958582e60207fed850b43426a6ff724 Mon Sep 17 00:00:00 2001 From: Diego Comas Date: Wed, 21 Apr 2021 10:51:50 +0200 Subject: [PATCH 2/2] fix broken link --- content/threat-intelligence.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/threat-intelligence.md b/content/threat-intelligence.md index 2120c82e3..4e0263faf 100644 --- a/content/threat-intelligence.md +++ b/content/threat-intelligence.md @@ -9,7 +9,7 @@ Cloud native applications by design and purpose are a collection of multiple dyn ## Projects - [MISP](https://www.misp-project.org/) - [Medallion - proof of concept](https://github.com/oasis-open/cti-taxii-server) -- [OpenCTI] (https://www.opencti.io) +- [OpenCTI](https://www.opencti.io) - [OSINT Framework](https://osintframework.com/) - [Threatcrowd](https://www.threatcrowd.org/)