Skip to content

Instantly share code, notes, and snippets.

@jeremy-donson

jeremy-donson/00-README.md

Last active October 23, 2022 09:54
Show Gist options
  • Save jeremy-donson/9fbf686eadf7956b94eef1b4fb63c42b to your computer and use it in GitHub Desktop.
Save jeremy-donson/9fbf686eadf7956b94eef1b4fb63c42b to your computer and use it in GitHub Desktop.
Download ZIP
Open Source Admin Team Security Training Jumpstarts - 2022
Raw
00-README.md

Open Source Admin Team Security Training Jumpstarts - 2022

  • Audiences: Open Source Tech Admins, Trainers, Trainees and Business Stakeholders

    • Each audience gets their own docs.

  • "People will come to love their oppression, to adore the technologies that undo their capacities to think." - A. Huxley

  • Audience Descriptions

    • Business Stakeholders

      • Identify when back end admin teams are required.
      • Consider both advantages and disadvantages of this scaled up back end team staffing pattern.
      • Learn to read high-level security modeling and testing diagrams.

    • Trainees

      • Plan to iteratively shift from in-person => remote.
      • From siloed study to test-driven team collaboration and social learning in three brief lessons.
        • 1: Local System + Web Service Setups + Analyze Syllabus
        • 2: Watch Lesson Demos + Follow Along + Document Learning
        • 3: Learn How Test-Driven Techniques To Define and Solve {network,system,data} Security Issues
      • Engage others to join in-person and online, amd help with their getting onboarded.

    • Trainers

      • From in-person 1:1 to remote team training and collaborations.
      • Gather and refine guiding questions.
      • Design test and validate: syllabus, curriculum, lessons and assessments.

    • Admins

      • We confront many security threats inherent to web-enabled systems and networks
      • We learn of many additional security threats inherent to admin teams.
      • Identify terms of both inter-admin dependency + autonomy with regard to security.
      • Next we solve those problems which we cannot eliminate in a test-driven fashion both locally + remotely:
        • physical machines + clusters (bare metal)
        • virtual machines + clusters (vms)
        • containers + services (microservices)

  • Types of Back End Admin Teams

    • Infrastructure • Networks • Systems • Automation • Data/Storage • AppDevOps • SecurityOps

Table of Contents

Prerequisites

  • Local System Tools:

    • gmail
    • gdrive
    • diagrams.net
    • signal
    • slack
    • gists
    • git
    • github
    • vagrant
    • docker
    • vagrant cloud
    • dockerhub
    • jira

  • Some specific installation prereqs as per local system type:

  • NOTE: All Local System Prerequisites Are Free. :)

  • Prerequisites Hands-On Skill For Trainees

  • Trainer Prerequisites

    • Tools => Terminology => Skills => Barter Options => Labs => Challenges => Projects

Security Realms + Scopes + Targets

  • Breach Candidates With Data Targets:

    • Individuals
    • Individual Devices
    • Teams of People
    • Networks of Devices

  • Security Realms / Scopes:

    • Personal Security
    • Family Security
    • Business Security
    • Customer Security

  • Data Sources Which Require Security

    • Financial Data Security
    • Medical Data Security
    • Legal Data Security
    • Service or Host Admin Data Security
    • Service or Network Admin Data Security
    • DBA Admin Data Security

Guiding Questions:

  • Stakeholders

    • When are back end admin teams required?
    • What kinds of security modeling and testing will be required for non-admin individual security??
    • What kinds of security modeling and testing will be required for non-admin team security??
    • What kinds of security modeling and testing will be required for solo admin security??
    • What kinds of security modeling and testing will be required for paired admin security??
    • What kinds of security modeling and testing will be required for team admin security??
    • How do banks handle these problems?
    • Where might security-first approaches be necessary?
    • Where might security-first approaches be overkill?

  • Trainees

    • When are solo workflows acceptable?
    • When are team workflows required?
    • Are multi-admin security problems confined to system security?
    • Do these multi-admin security problems exist for network and data security as well?
    • Must we harden the system first, or should we solve this multi-admin problem first?
    • How do we harden networks to avoid admin access hacks?
    • How do we harden linux operating systems to avoid hacks of root account?
    • How do we harden data processing clusters to avoid hacks of DB root@localhost account?
    • Are multiple admin users or sudoer access required? Why? Why not?
    • Can these serious security threats be tested in QA environment?
    • Can these serious security threats be solved in QA environment?
    • Can these serious security threats be monitored in PRODUCTION environments?
    • What are terms of least privilege for service accounts?
    • What are terms of least privilege for admins?
    • What are terms of least privilege for devs?
    • What types of diagrams help clarify LAN and WAN security modeling and testing?
    • How are zero-trust security models + testing + implementations proven to be superior?
    • Do zero-trust security models + testing + implementations/policies apply to admins as well?
    • Which industries cannot afford to be other than security-first?

  • Trainers

  • Open Source Admins + Engineers

Network Security

  • LAN Security
  • WAN Security
  • Stealth Mode Options

System Security

  • The "Multiple Admin Problem"

  • Too Many Admins?

  • Below, we concern ourselves with this problem such that scope is limited to single linux server host.

    • As we provide tests and proposed solutions, we can widen the scope to include 2+ linux server hosts.
    • In addition to the tested solutions below, we discuss the very same problem in the context of cloud computing.

Benefits of Multiple Concurrent Admins:

  • As environments scale up, running 24/7, multiple admin redundancy per system is the de facto standard.

  • If an admin loses their credentials, or needs them refreshed, then how do they get restored?

  • Often secure process requests will require 2+ admins to approve the request.

  • What happens when an admin gets sick or leaves the company?

  • These benefits are compelling. Can you identify other such benefits?

Caveats of Mutiple Concurrent Admin Sessions:

  • Lack of awareness of other local concurrent admin processes make any admin process a possible system stability risk.

  • Collisions become possible, especially when 2+ admins are trying to fix the same thing on the same system. :(

  • Service accounts are often in need of root privs, so they bear the same scrutiny as any sudoer access.

  • Auditing which sys admin did what on which system becomes obfuscated.

    • "Who made that change last week on this system?" => "The logs say root did it" :(

  • These caveats are unacceptable in many environments. If we cannot eliminate all unacceptable caveats in a given environment, then it gets tempting to set a hard limit on the number of concurrent admin users and/or user sessions. That creates other admin access problems. Since the benefits are often necessary, solving this ugly team admin security problem is often required. Can you identify any other such system security caveats? What about when these devices are virtualized and in the cloud?

Proposed Manual Testing + Solutions

  • Post Mortem Efforts:

    • How do we identify sudoer user and group privs on linux?
    • Do standard linux system logs reveal who has made sudo calls?
    • How do we capture those sudoer access request data points?
    • How do we add these data points to the linux system logs?

  • Real Time Efforts:

    • Review pending service accounts + scheduled run queue.
      • Pause queue until admin work is done if there are concerns.

  • Preventive Efforts:

    • Use the wall command prior to sudoer access requests to alert others on linux system.
    • Use the last command to identify who else is logged into this system.
    • Make /etc/ directory a root-managed git repo.. This allows ALL system changes to be tracked and versioned.
    • Monitor for concurrent admin sessions, including by a single admin user and root-privileged service accounts.
    • Read-only admin accounts can support root-level monitoring while permitting no local admin writes. Note that these admins can still use resource-intensive read-only calls to bring hosts to their knees. Therefore, we may opt to limit resource consumption of read-only admin commands.

Admin Security Realms & Scopes & Privileges

Data Security

Machine Security

Appliance + Device Security

Container Security

Core Tools + Services

CKA Training Labs

CKS Training Labs

Team Admin Challenge Scenarios

Team Admin Dojo

Core Terminology

  • Fundamentals
    • venn diagrams
    • compare : contrast
    • security : access
    • public : private
    • open source : proprietary
    • physical : virtual
    • local : remote
    • hardware : software : computer : machine : host
    • auditing : compliance
    • relative : absolute
    • groups : roles
    • developers : admins : engineers
    • ladders of dependency
    • system : components
    • onboarding : offboarding
    • authentication : authorization
    • single-point-of-failure : back door + other redundancy options
    • types of scaling up
    • scale up : scale out
  • Team metaphors + analogies:
    • music
      • symphonies
      • repertoires
    • kitchens
      • bakers
      • recipes
      • prep
      • production
    • building architecture
      • construction workers
      • plumbers
      • civil engineers
      • architects
      • locksmiths
      • police
  • Novice Level
    • operating systems : programming languages
    • ascii : binary
    • process : data
    • interpreters : compilers
    • read : write : execute
    • ram : disk
    • BIOS : Firmware : Filesystems
    • model : system
    • diagram : legend
    • lan : wan
    • monolithic architectures : microservices
    • stateful : stateless
    • encrypt : decrypt
    • decryptable : undecryptable
    • parse : format
  • Intermediate Level
    • data flow diagrams
    • logical data models
    • case tools
    • workflow diagrams
    • layers of stack : environments
    • environments : code pipelines
    • egress : ingress
    • Infrastructure as Code (IAC)
    • IAAS Platforms
    • PAAS Platforms
    • SAAS Platforms
    • memory constructs : files+folders+volumes
    • keys : tokens : certificates
    • deterministic : non-deterministic : random
    • cipher : algorithm
    • registry
    • dmz
    • services --< protocols
    • scale --E
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment