Presented at 'the fifth Israeli conference on software architecture' http://www.sw-arch2018.iltam.org

1. SECURITY DESIGN PATTERNS
Ofer Rivlin
Product Security Architecture Lead
1
5TH ISRAELI CONFERENCE ON SOFTWARE ARCHITECTURE

2. Product security architecture lead at CyberArk
10 years as a cybersecurity architect and researcher
10 years as a software & system architect & developer
(not overlapping )
Passionate about innovative technology and cybersecurity
OFER RIVLIN
2

3. Review of 4 security design patterns
Covering description & standard, examples, threats and risks of fixing after the fact
• Clear separation between layers
• Segregate components
• Centralized security controls
• Fail securely
• Minimize attack surface area
• Separation of concerns (duties)
• Principle of defense in depth
AGENDA
3
• Avoid security by obscurity
• Principle of least privilege
• Zero trust
• Establish secure defaults
• Use a low-privilege account for app components
• Keep sensitive data out of client-side code
• Keep security simple
• . . .

4. Review of 4 security design patterns
Covering description & standard, examples, threats and risks of fixing after the fact
• Clear separation between layers
• Segregate components
• Centralized security controls
• Fail securely
• Minimize attack surface area
• Separation of concerns (duties)
• Principle of defense in depth
AGENDA
4
• Avoid security by obscurity
• Principle of least privilege
• Zero trust
• Establish secure defaults
• Use a low-privilege account for app components
• Keep sensitive data out of client-side code
• Keep security simple
• . . .

5. • Security layer
• Well designed architecture can prevent attacks even if there
are vulnerabilities
WHY DESIGN PATTERNS
5

6. • Security layer
• Well designed architecture can prevent attacks even if there
are vulnerabilities
• Must be part of any architecture
WHY DESIGN PATTERNS
6

7. • Security layer
• Well designed architecture can prevent attacks even if there
are vulnerabilities
• Must be part of any architecture from day #1
WHY DESIGN PATTERNS
7

8. 8
CLEAR SEPARATION BETWEEN LAYERS

9. Ensure there is a clear separation between the
data - controller – display
layers
such that security decisions can be enforced on
trusted systems
CLEAR SEPARATION BETWEEN LAYERS
9

10. 10

11. • Malicious code injected as ‘Data’ and executed by the Controller
• Malicious code execution and affects Data Confidentiality and Integrity
• Confidential data exposed by Presentation layer
THREATS
11

12. 12

13. • Very high effort
• Redesign and re-implementing big parts of the solution
RISKS OF FIXING AFTER THE FACT
13

14. 14
SEGREGATE COMPONENTS

15. Ensure that components are
segregated
via a defined security control such as
network segmentation
firewall rules
etc.
SEGREGATE COMPONENTS WITH SECURITY CONTROLS
15

16. 16

17. • Adversaries and malicious code travel between components
• No authorization control between the different components
THREATS
17

18. 18
Server SK
Server PK

19. • Potential for a very high effort
• May require redesign and reimplementation due to dependencies
• May require redesign of the authorization model
RISKS OF FIXING AFTER THE FACT
19

20. 20
CENTRALIZED SECURITY CONTROLS

21. Verify that all security controls
(including libraries that call external security services)
have a
Centralized
implementation
CENTRALIZED IMPLEMENTATION FOR SECURITY CONTROLS
21

22. 22

23. • Authentication
• Authorization
• Input validation
• Output validation (XSS, errors, etc.)
• Audit logging
• APIs and pages
• Anti CSRF
EXAMPLES OF AFFECTED CONTROLS
23

24. • Missing Controls (forgotten)
• Not updated Controls
THREATS
24

25. • Very high effort
• Rewiring of every object to this control, sometimes in several places.
• Risk of forgetting to connect objects or different places
• Similar to implementing non-centralized controls
RISKS OF FIXING AFTER THE FACT
25

26. 26
FAIL SECURELY

27. The solution should always
stay secure
also in a failure
FAIL SECURELY
27

28. 28

29. 29
Android debug bridge daemon
Android Host

30. 30

31. 31

32. 32

33. 33
Android Host
Android debug bridge daemon

34. 34
Android Host
Android debug bridge daemon

35. 35

36. 36

37. 37

38. 38

39. 39
SUMMARY

40. • Security layer
• Must be part of any architecture from day #1
SUMMARY
40

41. SUMMARY
41
We reviewed these patterns
• Clear separation between layers
• Segregate components
• Centralized security controls
• Fail securely

42. We reviewed these patterns
• Clear separation between layers
• Segregate components
• Centralized security controls
• Fail securely
SUMMARY
42
Not covered patterns in this talk
• Minimize attack surface area
• Separation of concerns (duties)
• Principle of defense in depth
• Avoid security by obscurity
• Principle of least privilege
• Zero trust
• Establish secure defaults
• Use a low-privilege account for app components
• Keep sensitive data out of client-side code
• Keep security simple
• . . .

43. THANK YOU!
Ofer Rivlin
Product Security Architecture Lead
ofer.rivlin@cyberark.com
43