Starting Up Security

Starting Up Security

This section is a summary of the Starting Up Security website

Rainbow Series

🟪 Foundations ⭐️

• A mission for the security team
  • A security team typically aims to:
    1. 📉 Reduce risks
    2. 📈 Increase trust
       1. Trust is often a byproduct of transparency from an organization’s risk reductions
       2. A security team will burn out unless they are working efficiently to improve risks and trust
    3. ✅ Comply with governance
    4. 🚀 Empower the organization
  • There are two starting patterns that are safe to consider for early programs:
    1. Risk Assessments: Study and prioritize risks, then consider mitigations → ⭐️ magoo/minimalist-risk-management
    2. Best Practices: Study and prioritize gaps, then fill them
  • They’re in conflict with each other: one wants to assume that best practices will be the most efficient mitigators of risk, and the other wants you to study those risks before deciding on a mitigation
• How does a security team work?
  • See also Classifying types of Security Work

Area	Description
Business Projects	How does security help with new business efforts? A defining factor of business projects is that security can anticipate involvement and plan their involvement Example: A business might be launching a new software product. A security team will get involved to reduce vulnerabilities to the company or consumers using it
Operations	What ongoing tasks are security engineers committed to accomplishing? A decision to mitigate a risk might commit a security team to own operational work Operational work, while necessary, is often a target to be minimized or eliminated through automation Examples: A detection pipeline might require an on-call employee to respond to alerts The follow-up work from vulnerability scanning A security awareness program. A typical output of these programs is training
Engineering	How does security make investments for a better future? A security team often invests in itself to expand its ability to support the business and eliminate toil Examples: Integrating static analysis into a build pipeline may discover issues in business projects more quickly Automating the analysis of suspicious emails to reduce the amount of operations time spent investigating benign links Segmenting an untrustworthy part of the network exposed to a vendor may reduce unplanned incidents
Incidents (Unplanned)	What takes attention from planned work? Unplanned work inspires business projects, operations, and security engineering Business projects and security operations feed work into engineering Engineering projects march toward a better state of being

🟦 Management

• Hiring: Who the right will be, and when it makes sense to hire them
  • Hire a team, not a person
  • Task management is a reliable value across the workplaces cultures
  • There are clear partners across the company
  • Budget is available to support a security employee
  • Self-organization has begun around security responsibilities: Security is not a vertical set of tasks. Rather, security is best shared horizontally across an organization
• Leadership: Qualities that might be desirable in a security leader
  • Proper talent will want to become familiar with three things:
    1. Risks to the organizations
    2. Deficits of trusts to the customer
    3. Governance requirements
  • They can balance work
    1. Risk: Prioritizing work to mitigate the consequences of an undesirable event
    2. Trust: Prioritizing work that develops trust among our customers or peers
    3. Governance: Prioritizing work that meets certain compliance objectives
• Budget: Reasoning through budget discussions with a security team
• Planning: Encouraging risk based knowledge workers to offer direction
  • A collaborative planning process allows for the maximum available expertise about an organization’s risks
    • All security team members are expected to think critically about risks
    • Team leadership should set broad direction and strategy
    • A collaborative process captures this knowledge and formulates a directed roadmap
  • OKRs have issues
    • Other engineering disciplines can directly measure their key results
    • However, risk has roots in probability. Our teams cannot objectively measure “Probabilistic” outcomes. They can only forecast them, which is subjective
    • Security teams often focus their key results on obtainable, actionable goals around a risk-based objective. Part of the objective discussion can include specific risk targets that discuss scenarios
  • Objectives should have defensible roots in risk, trust, or compliance goals
• Performance: Framing the performance problem of risk based knowledge work

🟩 Fundamentals ⚒️

• The fundamentals are practices (best practices, standards, checklists, maturity models) that eliminate wide areas of risk
• Fundamental ojectives:

Objective	Description
Centralize and improve logging	Decide/Build/Buy a central logging platform or service Decide on critical logs that are critical for investigations Decide/Build/Buy an ingestion strategy Design procedure/playbooks for important investigations Test playbooks
Improve employee responsiveness in reporting incidents	Create #security aliases across chat, email, and tasks Launch a propaganda campaign to evangelize the #security alias Maintain a 1 hour SLA in #security ticket acknowledgment for one quarter
Reduce the risks associated with vendors	Establish process with legal to escalate data contracts Scan expenses and corporate credit cards for shadow IT vendors Add vulnerability and incident disclosure guidelines to high-risk contracts Add penetration testing language exceptions to all contracts Build rolodex for vendor security teams
Reduce the risk of insider abuse	Improve log coverage in administrative tooling Build detection for high-risk actions on high-value accounts Build threshold-based approvals to account deletion/account transfers Build employee role grants through manager approval Build auth token service based on customer approval
Reduce the risk of an endpoint compromise	Discover, estimate volume, and retrospective unmanaged hosts Improve HDD encryption coverage past N% Choose/Eval/Deploy EDR product Build and test termination and theft runbooks Decide on patch strategy for highest risk endpoint vulnerabilities
Improve responsiveness to incidents	Write an incident response plan Create rolodex for external IR partners Select and train internal IR partners Set up internal communications for compromised scenarios
Reduce the risk of remote IaaS API compromise (leaked credentials)	Design/Deploy network restrictions Design/Deploy a strong authentication strategy Choose/Demo/Deploy log ingestion pipeline Choose/Eval/Deploy secrets storage Spend N days on vulnerability finding. Fix all critical issues
Reduce the risks of a SaaS account compromise	Choose/Demo/Deploy SSO and MFA Vendor Create a rollout plan for company-wide SSO Estimate # of “Shadow” IT applications being used. Migrate auth towards it Build and deploy “Shadow IT” detection. Migrate auth towards it Follow a similar rollout for infrastructure and production
Lay groundwork for secure development practices	Discuss/Decide on engineering quality standards (with ENG) Discuss/Decide on secret storage (with ENG) Add security engineering to the product development workspaces Build security “boot camp” for engineering onboarding Build vulnerability management standards
Lay groundwork for future detection efforts	Design/Build/Deploy log management pipeline Decide on alerting and detection strategy Recruit and select on-call rotation Buy/Build on-call incident platforms Build detection/alerting for three risk areas
Lay groundwork for future risk management efforts	Create a risk register Interview n organization partners and model top risks Decide on future periodicity of re-assessments Update “priority risk” documentation Represent risk priorities in planning meetings
Lay groundwork for finding and fixing	Spend n days vulnerability finding Write up vulnerabilities for policy discussions Decide on SLA’s / Criticality with IT and Engineering Create a central location for known vulnerabilities and associated tasks

🟨 Building

• Avoid “shadow IT” anti-patterns:
  • Security is hired into a non-engineering reporting chain
  • Security is excluded from engineering roadmap discussions
  • Security makes unique technology choices and owns separate source code management
  • Security lower and has inconsistent hiring and interviewing standards
  • Security has lower and inconsistent development and deployment standards (style, peer review, testing)
• Engineering Identity
  • Builders should be indistinguishable from their partners: IT, Product, Engineering
  • Share identity with partner organizations:
    • Security reports to engineering leadership
    • Planning and roadmapping should be inclusive of security efforts
    • Security shares the organizations technology standards and development practices
    • Security hiring maintains and contributes to the hiring bar
    • Security mitigations are rolled out with product launch / deployment standards
• Philosophy of fixing security issues with no clear owner
  • Security is not catch-all bug dumpster
  • Security does step in for unowned or specialist problems
  • Culture, values, leadership, and “whole team” approach to sharing the work

🟧 Breaking

• Breaking anti-patterns
  1. Breaking creates work for building
     • Resourcing for breaking and building is a Explore / Exploit Tradeoff
  2. Law of the Lever:
     • Breaking creates work
     • Breaking can create more work than you can mitigate
     • Incentives can worsen this this further
  3. Violating the lever can create internal hostility and toil
• On Fixing Bugs
  • Who Fixes That Bug? (Part One: Them!)
  • Who Fixes That Bug? (Part Two: Us!)

🟥 Incidents ⭐️

• Create an incident response plan to manage these changes → ⭐️ template, explanation
  • A rolodex of contacts: Law enforcement, Forensic, Legal, Leadership, and PR contacts who can come online quickly and contribute to a response
  • A template for collaboration: Incidents are often about managing uncertainty. What are questions we still have? Who is accountable for answering them? What are the short term emergency actions, and what are the long term learnings?
  • Approval Points: Who approves an emergency blog post, an email to customers, or calls law enforcement? Pre-approvals for expected steps will avoid delays and meetings
  • Internal Communications: Who communicates issues with employees?
• Dependencies
  • Your readiness for an incident depends on leading project work
  • Incident response can be practiced with tabletop or red team exercises
• See also Security Breach 101 and Security Breach 102

Security Strategy

From the Starting Up Security article

Products ⚒️

• Relates to the quality of application development

Area	Description
Strict Engineering Standards	NOW: Build into a strong culture of strict code review LATER: Engineers can build reusable security frameworks that globally handle common issues within your applications Trigger audits on high risk code for extra review Treat every security bug as an incident, document it for posterity and push the lessons onward to new and current engineers Enforce mandatory postmortem of security bugs for leadership, like you would with an outage
Vulnerability Disclosure and Bug Bounty	NOW: Set up a policy that protects security researchers when they disclose vulnerabilities to you, and reward them when they discover security issues with your products LATER: Make it an engineering goal to have the most expensive bugs possible
Engineer Onboarding	NOW: Invest quality time in new engineers and inform them on security sensitive areas of the codebase (Auth, DB, Sessions, Crypto, etc) Calibrate code review expectations to the same high standard others will expect Introduce them to security minded folks and make it OK to reach out for help, and show them where security questions can go Build a place for security questions to go (a mailing list, IRC channel, chat room, Google Group, etc.) LATER: Integrate the history of severe security bugs from version control, bug bounty, and auditor findings into education Teach, in detail, the tools and tactics your relevant attackers would use against your product
Manage Secrets	NOW: Review the crypto around your storage of passwords Review how many people have access to private keys and certificates Ensure that infrastructure touching credit cards doesn’t go neglected Build services that can make it simple to keep secrets out of source code

Infrastructure ⚒️

• Relates to the quality of the systems that support the applications

Area	Description
Authentication	NOW: Multifactor every form of authentication that exists Lock down root usage to better reflect the activity of individuals on systems Ensure that prolific root usage doesn’t become the standard for regular administration and deployment Root usage should be treated as an extreme anomaly with heavy alerting LATER: Focus on authorization, “need to know” and least access
Patching	NOW: Your operating systems, kernels, applications, libraries and other dependencies all need to be updated Treat patches that fix remotely exploitable bugs with the highest priority LATER: Build patch automation within continuous integration Remove dependencies that can’t be automatically updated or frequently introduce breaking changes Keep an eye on Google alerts, Full-Disclosure, and various vulnerability feeds like the National Vulnerability Database for software you’ve deployed Regularly schedule vulnerability scanning with enterprise versions of tools like Nessus, Rapid7, etc, with success measured around reduced known vulnerabilities and low windows of exposure between patches
Centralized Logging	NOW: Push system and application logs somewhere centralized and in a separate risk area from the rest of your infrastructure Ensure that SSH logs and any internal tools you’ve built log here Build basic alerting that would tip off engineers when systems are accessed without permission LATER: Scale this log store and build tools that make review easier or unnecessary Make these log stores trivially accessible to an incident responder who is working as fast as they can Make sure alerting happens when logs stop flowing Build log failures into regular incident meetings

Employees ⚒️

Area	Description
Endpoint	NOW: Purchase employees laptops to separate home & work life Standardize everyone on Chrome configured with Click to Play Understand and train employees about spear phishing Enable disk encryption Build a checklist so employees can self-certify to this standard when they’re hired LATER: Build laptops with these configurations pre-imaged, or managed via a centralized system like chef Don’t rely on a employee to-do checklist Start employing tools like osquery to understand what is being installed across your corporate fleet Be able to swap out laptops displaying suspicious behavior quickly with new machines to keep employees working
Shared Passwords	NOW: Train employees about the risk of shared password usage between your employees personal lives and corporate accounts Pay for Lastpass or 1Password so they can manage the nightmares created by actually secure password management Push multifactor authentication for personal lives as much as corporate usage LATER: Systems like Okta, Meldium, Bitium, all help centrally manage credentials for the disparate cloud applications your employees will use. They will also help enforce uniqueness, multifactor, and termination scenarios Additionally, you can take advantage of SAML (either in house or provided) to centralize authentication as well