What is a modern, dynamic service and its' building blocks?

When I look at the Cloud Native ecosystem, I am astonished.  The vendor space’s market capitalization is near $7.78 trillion with funding of $12.26 billion.  Below is a rough ecosystem image.

 

As I work through the ecosystem, there is no evident, leading “best practice. Within modern, dynamic environments, there are not obvious answers to empower an organization to build and operate scalable applications.  There are no best practices to enable loosely coupled, resilient, manageable, and observable systems.  Much less do not require 5 FTEs to enable repeatable, predictable, high-impact outcomes. 

 Below are high level challenges one will solve as they build and run their modern, dynamic service:

Containerization

  • Commonly seen with Docker

  • Any size and dependencies may be containered

  • Eventual microservices architecture


Registries and Runtime Execution

  • Harbor.io is a great registry which stores, signs, and scans container content.  When hooked into Clair, may provide vulnerability information

  • If docker isn’t your thing, OCI-compliant containerd, rkt, and CRI-O work great


Distribution

  • An implementation of the Update Framework, Notary, is great to start off distributing your services


CI / CD

  • Changes to the source code automatically result in new containers built, tested, and deployed

  • Hopefully canary with blue / green deployments

  • Automated deployments, rollbacks, and testing

  • Orchestration and Application Definitions

  • Kubernetes is leading the orchestration market

  • Aim to utilize a certified Kubernetes distribution or hosting platform

  • Helm charts enables one to define, install, and upgrade even complex Kubernetes enabled services


Analysis and Observability

  • Find the right services for logging, tracing, and monitoring

  • Prometheus is great for monitoring

  • Fluentd is wonderful for logging

  • Jaeger isn’t bad at tracing.  Otherwise, look for an Open-Tracing compatible solution


Discovery, Mesh, and Proxy

  • CoreDNS is flexible and fast.  Great for service discovery

  • Linkerd and Envoy enable mesh architectures, health checking, routing, and load balancing


Networking Policy Enforcement

  • Istio, Flannel, Calico, or Weave Net are decent general purpose network policy engines

  • Uses range from authorization and admission to data filtering


Database and Storage

  • It really depends on the storage type

  • If one is utilizing MySQL, Vitess works to scale and shard

  • Rook works as a storage orchestrator

  • Etcd provides mechanisms to store data across clusters

  • TiKV works well as a highly performant transactional key-value store


Streaming and Messaging

  • When JSON-REST is not enough, gRPC or NATS is the way to go. 

  • Generic RPC usage is implemented in gRPC

  • Complex messaging utilizes NATS (pubsubhub / subscriptions, request / reply, load balancing, etc..)

 

 

A collection of Bug Bounty polices and statements to run a program

Recently, a friend reached out to me for a simple Bug Bounty vulnerability disclosure policy. While combing through my vulnerability disclosure polices library, I realized there wasn’t an acceptable policy to be found.

The default policies for the popular bug bounty platforms leave much to be desired or are wrapped in legalese not easily understood by those whom English is a second / third language.

Below is a simple policy which can be applied to ones’ bug bounty program. Enjoy!

Vulnerability Disclosure Policy

INSERTENTITYNAME is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.

Program Rules

  • Automated testing is not permitted.
  • Follow INSERTBUGBOUNTYPLATFORMNAME’s Disclosure Guidelines - URL TO BUG BOUNTY PLATFORM DISCLOSURE GUIDELINES
  • Test only with your own account(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.
  • You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.
  • We award bounties at time of fix, and will keep you posted as we work to resolve them.
  • Contacting our support team ([email protected]) about the status of a INSERTBUGBOUNTYPLATFORMNAME report will result in an immediate disqualification for a bounty for that report.

Exclusions

The following bugs are unlikely to be eligible for a bounty:

  • Issues found through automated testing
  • "Scanner output" or scanner-generated reports
  • Publicly-released bugs in internet software within 3 days of their disclosure
  • "Advisory" or "Informational" reports that do not include any INSERTENTITYNAME-specific testing or context
  • Vulnerabilities requiring physical access to the victim's unlocked device
  • Denial of Service attacks
  • Brute Force attacks
  • Spam or Social Engineering techniques, including:
  • SPF and DKIM issues
  • Content injection
  • Hyperlink injection in emails
  • IDN homograph attacks
  • RTL Ambiguity
  • Content Spoofing
  • Issues relating to Password Policy
  • Full-Path Disclosure on any property
  • Version number information disclosure
  • Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)
  • CSRF-able actions that do not require authentication (or a session) to exploit
  • Reports related to the following security-related headers: Strict Transport Security (HSTS) XSS mitigation headers (X-Content-Type and X-XSS-Protection) ** X-Content-Type-Options
  • Content Security Policy (CSP) settings (excluding nosniff in an exploitable scenario)
  • Security bugs in third-party applications or services built on INSERTENTITYNAME's APIs - please report them to the third party that built the application or service
  • Security bugs in software related to an acquisition for a period of 90 days following any public announcement
  • Former INSERTENTITYNAME employees within one year of their departure from INSERTENTITYNAME

Safe Harbor

Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

Thank you for helping keep INSERTENTITYNAME and our users safe!

Scope

There are far too many posts about determining scope. if you are not sure what to do, the below scope and severity is a great start.

ProgramScope.PNG