The currently generally accepted properties of microservices can be summed up as follows: They are small and plentiful. They collaborate over the network. They are often built using different technologies by autonomous teams. These teams assume end-to-end responsibility for their creations and follow DevOps and Continuous Delivery principles. They also tend to be deployed as software containers using Docker. Each one of these properties individually can make traditional information security managers shudder. A large attack surface due to the great number of network services, which are built and run by teams with possibly little security expertise. Changes deployed to production multiple times a day, often without any human intervention or sign-off. All that using whatever new tech stack the team in charge sees fit and run in overhyped container technology, which has yet to be proven in production. This talk explored if the situation is really that dire, or if the properties of microservices can possibly even strengthen information security in your organisation.

1. Microservices –
a security nightmare?
GOTO Nights Zürich - March 3, 2016
Maximilian Schöfmann | @schoefmann
Container Solutions Switzerland

8. Microservices (2016) …

9. Microservices (2016) …
small, hence many services

10. Microservices (2016) …
small, hence many services
talking over the network

11. Microservices (2016) …
small, hence many services
talking over the network
built with different technologies

12. Microservices (2016) …
small, hence many services
talking over the network
built with different technologies
by autonomous teams with end-to-end responsibility

13. Microservices (2016) …
small, hence many services
talking over the network
built with different technologies
by autonomous teams with end-to-end responsibility
doing DevOps and Continuous Delivery

14. Microservices (2016) …
small, hence many services
talking over the network
built with different technologies
by autonomous teams with end-to-end responsibility
doing DevOps and Continuous Delivery
using containers

15. Microservices (2016) …
small, hence many services
talking over the network
built with different technologies
by autonomous teams with end-to-end responsibility
doing DevOps and Continuous Delivery
using containers

16. Microservices are the result of combining
architectural ideas from lightweight SOA
and Domain Driven Design,
organisational approaches like DevOps
and Agile Software Development, and
technology innovations like Containers
and Programmable Infrastructure

17. Architecture Organisation
Technology

18. Monolith

19. “many small services”

20. Monolith - method calls

21. Microservices - talking over the network

22. Java 7
(1.7.0_03)
Monolith - few technologies

23. Microservices - built with different technologies
nodejs
0.9
Ruby
2.1
Java 7
Go 1.4
Java 8

24. Security Gates vs…

25. … autonomous teams
with end-to-end responsibility

26. … autonomous teams
with end-to-end responsibility

27. dedicated security experts vs…
(ISC)2®

28. doing DevOps
OWASP
??

29. classic “Security Sandwich” vs…

30. classic “Security Sandwich” vs…
Specification
Implementation Validation

31. … Continuous Delivery

32. well isolated “real server” vs…

33. … using containers

34. Attack surface - VMs vs containers
XEN Hypervisor - 10^5 LOC
Linux Kernel - 10^7 LOC

37. Highly coupled services
No clear boundaries

38. Loosely coupled services
Clear boundaries

39. many small services

40. impact of breach can be contained locally

41. “Clear service boundaries
limit the impact of breaches”

42. Keep APIs minimal

43. payment_
data
(stateless)
cat_
pictures
(stateless)
user_db
Microservices have their own data store

44. payment_
data
(stateless)
cat_
pictures
(stateless)
user_db
Microservices have their own data store

45. “Let the need-to-know principle
guide your API design”

46. payment_
data
(stateless)
cat_
pictures
(stateless)
user_db
different security levels should require different security
properties in services, e.g. encryption, auth, security testing…

47. “Classify services into distinct
security levels”

48. API Gateways
API Gateway

49. API Gateways
API Gateway
• Access control
• Rate limiting
• HTTPS termination
. . .

50. API Gateways
API Gateway
WAF Payment Svc.

51. “Isolate services with different
security levels through gateways”

52. Authorization & Authentication

53. Authorization & Authentication

54. “Use scalable auth techniques
without single points of failure”

56. Secrets management
vaultproject.io square.github.io/keywhiz

57. “Manage secrets with special
purpose services”

59. Freeze image for analysis
payment
service
instance #2
docs upload
service
instance #1
payment
service
instance #1
cat picture
service
instance #1
meme
generator
instance #1
bookmark
manager
instance #1
payment
service
instance #1

60. Or even the running container… (criu.org)
payment
service
instance #2
docs upload
service
instance #1
payment
service
instance #1
cat picture
service
instance #1
meme
generator
instance #1
bookmark
manager
instance #1
payment
service
instance #1

61. “Leverage container features for
forensics”

62. Scheduling constraints
payment
service
instance #2
docs upload
service
instance #1
payment
service
instance #1
cat picture
service
instance #1
meme
generator
instance #1
bookmark
manager
instance #1

63. “Run services of different security
levels on different hosts”

64. Replace containers on deploy
payment
service
instance #2
docs upload
service
instance #1
payment
service
instance #3
cat picture
service
instance #1
meme
generator
instance #1
bookmark
manager
instance #1

65. “Embrace immutable infrastructure”

66. “built with different technologies”
nodejs
0.9
Ruby
2.1
Java 7
Go 1.4
Java 8

67. Monocultures…

68. Scanning images at rest
Clair (CoreOS)Nautilus (Docker Inc.)

69. “Scan images already during the
build process”

70. Container technology…
BSD Jails
2000
2001
Virtuozzo
Linux-VServer
Solaris Zones
2004
LXC
2008
2013
Docker
rkt
2014
1982
chroot
2007
cgroups

71. Docker security hardening…
container-solutions.com/security
• read-only containers
• minimal base images
• drop capabilities
• traditional hardening
(AppArmor, SELinux…)
. . .

72. “Minimise the attack surface of
images and hosts”

73. Unify & secure deployment methods
Simple to add…
• TLS
• Authentication
• Authorisation
• Logging & Auditing
• Image verification
scp
rsync
git

74. “Have a single, hardened
method to deploy”

76. …end-to-end responsibility

77. Gates and Accountability

78. Security Sandwich and Autonomy
Specification
Implementation Validation

79. Security Sandwich and Autonomy

80. Security Sandwich and Autonomy

81. Trust
Idea from A.T. Kearny Analysis
Accountability Expertise
Autonomy &
Entrepreneurship
Collaboration &
Support
Trust

82. Security aspects must become
part of the Definition of Done…

83. Rugged Software Manifesto
ruggedsoftware.org

84.
SecDevOps?
SecOps?
DevSec?

86. The role of IT Architects is already
changing
Now, the role of the Security Team
needs to change

87. “Accountability ensures security is
built in, not bolted on”

88. Avg: 103 days to fix a vulnerability
http://darkmatters.norsecorp.com/2015/06/09/security-vulnerabilities-take-average-of-103-days-to-remediate/

89. CD reduces reaction time

90. “Leverage Continuous Delivery as a
security feature”

91. Test pyramid
Unit Tests
Service Tests
UI tests
faster feedback
from “Succeeding with Agile” (Mike Cohn)
confidence

92. Security-Test pyramid / AppSec pipeline
static code analysis
Vulnerability
scanning
E2E
security tests
faster feedback
confidence

93. BDD style
continuumsecurity.net/bdd-intro.htmlgauntlt.org

94. “Have your test pyramid reflect
security”

95. Architecture Organisation
Technology

96. Architecture
Clear service boundaries limit the impact of breaches
Let the need-to-know principle guide your API design
Classify services into distinct security levels, which mandate
different security properties
Use scalable auth techniques without single points of failure
Isolate services with different security levels with gateways
Manage secrets in specialised services

97. Technology
Run services of different security levels on different hosts
Leverage container features for forensics
Embrace immutable infrastructure
Scan images as part of the build process
Have a single, hardened method to deploy
Minimise the attack surface of images and hosts

98. Organisation
Leverage Continuous Delivery as a security feature
Have your test pyramid reflect security
Accountability ensures security is built in, not bolted on

99. Nightmare?

100. maximilian.schoefmann@container-solutions.com | @schoefmann
container-solutions.com