Designing For Security From the Start

Susan Sons

IU-CACR, ICEI

sons@security.engineering

Goals For the Day

Code Longevity:

  • Resources

  • Personnel (devpower & expertise)

  • Repository & Access

  • Build System

  • Tests

  • Documentation

  • Communication Channels

High-Return Technical Improvements Accomplishments:

  • Code Access
  • Build Process
  • Testing Infrastructure and Automation
  • Documentation
  • Getting the architecture right.

Information Security Practice Principles (ISPP)

  • Comprehensivity:   Am I covering all of my bases?
  • Opportunity:   Am I taking advantage of my environment?
  • Rigor:  What is correct behavior, and how am I ensuring it?
  • Minimization:  Can this be a smaller target?
  • Compartmentation: Is this made of distinct part with limited interactions?
  • Fault Tolerance:  What happens if this fails?
  • Proportionality:  Is this worth it?

Across Time

  • The principles worked for Sun Tzu, for Augustus Caesar, for Cicero.
     
  • They work as well with paper and ink records as with digital databases.
     
  • They work on things I haven't thought of yet.
     
  • Quit starting over every couple of years.

Across Roles

  • What would happen if your programmers, systems administrators, policy-makers, managers, and information security experts all spoke the same language?

 

  • It doesn't help security if management doesn't know enough to prioritize, or the systems and code owners don't know enough to implement.

Death By Checklists

Where does information security

come from?

Just Seven Principles

Don't be this guy.

The Information Security Practice Principles (ISPP)

  • Comprehensivity:   Am I covering all of my bases?
  • Opportunity:   Am I taking advantage of my environment?
  • Rigor:  What is correct behavior, and how am I ensuring it?
  • Minimization:  Can this be a smaller target?
  • Compartmentation: Is this made of distinct part with limited interactions?
  • Fault Tolerance:  What happens if this fails?
  • Proportionality:  Is this worth it?

You've probably seen some of these before:

  • Comprehensivity:   End-to-end encryption, Inventory, Reconnaisance
  • Opportunity:   Information Sharing, Common Tools, Pentesting
  • Rigor:  Governance, Monitoring, Auditing, Follow-Through
  • Minimization:  Attack Surface, Compactness, Data Minimization
  • Compartmentation: Least Privilege, Forward Secrecy, Airgap, Clean APIs
  • Fault Tolerance:  Resilience, Revocability, Defense in Depth
  • Proportionality:  Usability, Risk Acceptance, Fighting to the Goal

The Principles

In Practice

Comprehensivity

Opportunity

Rigor

Minimization

Compartmentation

Fault Tolerance

Proportionality

The Information Security Practice Principles (ISPP)

  • Comprehensivity:   Am I covering all of my bases?
  • Opportunity:   Am I taking advantage of my environment?
  • Rigor:  What is correct behavior, and how am I ensuring it?
  • Minimization:  Can this be a smaller target?
  • Compartmentation: Is this made of distinct part with limited interactions?
  • Fault Tolerance:  What happens if this fails?
  • Proportionality:  Is this worth it?

Q & A

What makes devs' work harder?

About 10% of your team's time.

The Cost of Continuous Time Estimation:

Continuous Time Estimation with approval (assuming slowest response is 2-4 working hours):

15-20% of your team's time.

Q & A

Security Programs

(and why you care)

Security Needs

  • Rigor and regularity : do it consistently, and iterate over time
     
  • Authority without split agency:
    The authority and the responsibility lie in the same place
     
  • Resources
     
  • The ability to deal with incidents promptly and effectively

A Program Is:

  • A set of policy documents that capture scope, goals, and responsibilities as well as process.
     
  • A way to update the documents and policy/process.
     
  • A budget.
     
  • A policy for modifying or granting exceptions to the policy.

Minimum Viable Program

As NTPSec Project Manager, Mark Atwood accepts risk on behalf of the project.  In the event of a security incident, Information Security Officer Susan Sons is empowered to declare the incident and manage the NTPSec Project's response.  Security documents are maintained at <url>.

Policy Is a Tool

  1. Set up roles and responsibilities that work.
    **Avoid split agency at all costs.
     
  2. Document process so it can be iterated on.
     
  3. Capture what is being done and why, so that one can resource those efforts.
     
  4. Carefully document process for known scenarios, and responsibilities and goals for unknown scenarios.

Develop, Adopt, Educate, Follow, Enforce, Revise

The life of an infosec policy:

Develop, Adopt, Educate, Follow, Enforce, Revise

What usually happens:

Roles and Responsibilities

No one can eliminate every risk.

 

Neither the architect nor the ISO/CISO should accept risks.

Process:

Start light, iterate over time based on experience.

 

It can help to break out separate policies to minimize editing.

Goals and Scope:

The why tends to be as important or more important than the how.

 

If you don't agree what your team is responsible for, and what your priorities are, then anything not explicitly stated in policy can't be solved.

Emergency Procedure:

  • Make lines of authority and communication clear.
     

  • Start with your "black swans" and "grey pigeons"
     

  • Don't try to document every possible scenario: rely on
    people and resources.
     

  • This is all worthless if no one practices.

Money and Other Resources

This will always be your limiting factor.

Winning the budget game requires:

  • Being able to communicate exactly what your team is doing, and how it benefits the organization.
     
  • Showing what you should be doing, and what resources are required.
     
  • Offering ways to measure effectiveness:
    • Relative to multiple priorities
    • In response to changes in team, program, and organization
       
  • Seating risk in the lap of those who control the resources.

Security Culture

We all want to write secure code.

What we actually write is the best code that we can, while meeting all the other constraints and stressors on our work.

Distribution

Communicating About Security

Vulnerability Management

(if you think you have no vulns, you aren't looking hard enough)

Using and Sharing This Work:

Creative Commons License  Software Security Bootcamp: Architects' Edition by Susan Sons is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Permissions beyond the scope of this license may be available; send inquiries to sons@security.engineering .

Designing For Security From the Beginning

By Susan Sons

Designing For Security From the Beginning

  • 424

More from Susan Sons