delivering_security_products.pdf

01dad3d7bf0ae06c552a9e8c07ab6bfa?s=47 ShaD
October 15, 2018

 delivering_security_products.pdf

Delivering security products without shooting in a foot

Talk about improving the infrastructure for developing, testing and delivering security tools. Our experience of smoothing the difference between security idealism and engineering friendliness.

01dad3d7bf0ae06c552a9e8c07ab6bfa?s=128

ShaD

October 15, 2018
Tweet

Transcript

  1. 2.

    We will talking about: — Approaches, not instruments — CI/CD

    — Infrastructure — Workflow — Usability
  2. 7.

    What is the problem? Security teams create complex security products,

    developers want to have an easy way to use them
  3. 8.

    Why developing is so hard? — ingenious ideas — chaotic

    strategy changing — do not care about compatibility — testing in hothouse conditions — hard to deploy — hard to use properly
  4. 13.

    Our company specific: — we create crypthographic products — compact

    size of team — mostly engineering staff — horizontal structure — open-source products — multiple languages / platforms
  5. 14.

    What is critical for us? — automation — clear, transparent

    processes — responsibility — openness — safety — use own products — write docs
  6. 16.

    Let's divide solution into the parts: — architecture — workflow

    standards and rules — infrastructure — CI/CD
  7. 21.

    — on what platforms should our application work? — how

    many and what are the types of the components? — usability bounds of the different components? — what are the possible topology variants?
  8. 22.

    — how will they communicate? — how do we plan

    to scale? — what external dependencies will the product have? — what are possible vulnerabilities and risks in the planned architecture?
  9. 27.

    What are the external systems and how do we plan

    to integrate with? — basic functional systems — an application in which we integrate — databases — libraries — auxiliary systems — monitoring — SIEM
  10. 31.

    Logging — events — human-readable — standard output methods Formats

    and outputs File STDERR Syslog Plain text ✔ ✔ - JSON ✔ ✔ ✔ CEF ✔ ✔ ✔ syslog - - ✔
  11. 33.

    Tracing — detail analyze of successive data processing — intrusion

    detection — performance tuning — deep debugging Output — OpenTracing — OpenCensus — JSON
  12. 34.

    How will it be supported? — fast deploy scripts —

    troubleshooting information gathering tools
  13. 35.

    Workflow standards and rules — synchronize all team members —

    unify approaches — make the development results more expected and clear for our customers — simplify automation
  14. 37.

    The rules must: — be as simple and clear as

    possible — be kept actual — have a minimal impact on productivity — only correct, not break existing workflow
  15. 39.

    Versioning Semantic Versioning https://semver.org Format: a.b.c, where: a — major

    version, increases with significant changes of product b — minor version, increases with current releases, backward compatibility may not be guaranteed c — build version, increases with bug hotfixes, minor features' improvements
  16. 40.
  17. 41.

    Git flow and CI/CD Name Usage CI/CD automation stable Releases

    all tests, packaging, delivering master Current state all tests, packaging, delivering username/ GH999_issue_des c Dev, fixes manual
  18. 43.

    Infrastructure Part Requirements core safety, stable developing speed up, easy

    cross- communications CI/CD full automation, tests, packaging, delivery
  19. 44.
  20. 45.
  21. 47.

    Buildbot — unit tests — multiple platforms — crossplatform tests

    — integration tests — pre-release checks — packages building
  22. 49.

    CI/CD rules — emulate real customer environment — use system

    libraries — strict configurations — scenarios according to docs — easily maintained and extended — developers can add scenarios
  23. 52.
  24. 53.

    Docker image sizes — large image size is typical —

    most developers do not pay attention to the size — there are ways to significantly reduce the image — we reduced the size from ≈950MB to ≈15MB
  25. 54.

    What technologies did we use? — multi-stage builds — build

    from scratch You can find all dockerfiles at: https://github.com/cossacklabs/acra/tree/master/docker
  26. 56.

    Image tags Static tags — version tag — git commit

    tag Sliding tags — stable, latest — master, current
  27. 59.

    What was uncomfortable? — generate and manually place keys —

    configure parameters inside docker-compose file manually — one very simple example of configuration — topology was unclear — security perimeter was not visible
  28. 60.

    What now? — multiple demonstation stands — all stands can

    be launched in one action — confiurations can be easily extended and secured * — self-documented — topology described
  29. 61.

    Summary — complex security products require careful and accurate handling

    — iplemented standards — built large testing platform — release cycle: from once a year to once a couple weeks — from burst developing to planned releases — increased flexibility of our team — from concept researching to implementing usable features