Description: This presentation will start with an overview of the current state of Application Insecurity (with practical examples). This will make the attendees think twice about what is about to happen to their applications. The solution is to leverage a new generation of application security thinking such as: TDD, Docker, Test Automation, Static Analysis, cleaver Fuzzing, JIRA Risk workflows, Kanban, micro web services visualization, and ELK. These practices will not only make applications/software more secure/resilient, but it allow them to be developed in a much more efficient, cheaper and productive way. The v.06 was presented at London Software Craftsmanship Community on 18/Feb/2016 - http://www.meetup.com/london-software-craftsmanship/members/184071944/ The v.0.6 was presented at the OWASP London Chapter meeting on 25t/Feb/2016

1. N E W E R A O F S O F T WA R E W I T H
M O D E R N A P P L I C AT I O N S E C U R I T Y
V E R S I O N 0 . 6 ( 2 7 / F E B / 2 0 1 6 )
O WA S P L O N D O N C H A P T E R
@ D I N I S C R U Z

2. @ D I N I S C R U Z
• Developer for 25 years
• AppSec for 13 years
• Leader OWASP O2 Platform
project
• Head of Application Security at
The Hut Group
• Application Security Training for
JBI Training
• http://blog.diniscruz.com/
• https://www.linkedin.com/in/
diniscruz

3. Q U A L I T Y

4. Software Craftsmanship is about
Software Quality

5. a big problem with the Craftsmanship (and testing)
community is:
‘How to define Quality?’

6. Everybody knows that Quality is key
… but …
‘how to measure Quality?’

7. My thesis is that
Application Security can be used to
define and measure Quality

8. Application Security is all about the non-functional
requirements of software*
* software = apps, websites, web services, apis, tools, build scripts = code

9. Application Security is all about understanding
HOW the software work
* vs how software behaves

10. Using Application Security
I can measure the quality of software

11. Because Application Security
measures the unintended side effects of coding

12. W R I T I N G S E C U R E C O D E M Y T H

13. “If only software developers had security
knowledge they would be able write secure code”

14. This is a myth because secure code has very little
to do with developer’s skills and craftsmanship

15. Software security (or insecurity) is a consequence
of the Software development environment
(namely the business and managers focus)

16. And I know that this is a myth because
I cannot write ‘secure code’
when I’m programming

17. T H E P O L L U T I O N A N A L O G Y

18. T E C H N I C A L D E B T I S A B A D A N A L O G Y
• The developers are the ones who pays the debt
• Population is a much better analogy
• The key is to make the business accept the risk (i.e the
debt)

19. L E T ’ S H A C K ( A L I T T L E B I T )
H T T P : / / M A N I F E S T O . S O F T WA R E C R A F T S M A N S H I P. O R G /
Demo

20. C U R R E N T S TAT E O F A P P L I C AT I O N
I N S E C U R I T Y

21. How secure is your code?

22. How insecure is your code?
How many risks/vulnerabilities are
you aware of?

23. J I R A R I S K W O R K F L O W
http://blog.diniscruz.com/2015/12/jira-workflows-for-handing-appsec-risks.html

24. K E Y C O N C E P T S O F T H I S W O R K F L O W
• All tests should pass all the time
• Tests that check/confirm vulnerabilities should also
pass
• The key to make this work is to:
Make business owners understand the risks of their
decisions (and click on the ‘accept risk’ button)

25. You have to make sure that it is your
boss that gets fired

26. … he/she should make sure that it is
his/hers boss that gets fired …

27. … all the way to the CTO
(i.e. Board level responsibility)

28. S E N I O R M A N A G E M E N T O V E R S I G H T
• ‘Security Memo’ (from God)
• Incident response plans
• Emergency response exercises (can you detect them?)
• Cyber Insurance
• Enterprise Cyber Risk management
• Which C-level executive will get fired?

29. D O E S Y O U R C O M PA N Y / T E A M H AV E :
• AppSec team/person
• Security Champion
• Secure coding standards
• Threat Models
• OWASP contributors
• Secure code reviews

30. If your answer was not YES to all of them...
then
Your Application WILL have a high
number of Security Vulnerabilities

31. W H Y D O A P P L I C AT I O N S E C U R I T Y ?

32. Because you care about:
your users
good engineering
your application
your company

33. You have been lucky so far due
to lack of commercially focused
attackers

34. This has been a
Blessing and Curse

35. You are making
an Hedged bet

36. the
Security of your code
vs
Skill and motivation of attacks
will not change in next 2 years
Your hedge bet is that :

37. Most of you are creating the
perfect storm ….

38. User personalisation
+
Digital Payments
+
APIs

39. A large % of your apps users
will have malware on their
box

40. You are as secure as your
most unexperienced
developer

41. W H O I S AT TA C K I N G Y O U

42. I F T H E
AT TA C K E R T E L L S
Y O U A B O U T T H E
AT TA C K

43. Y O U S H O U L D
T H A N K T H E M

44. The dangerous ones are the
commercially focused
criminals

45. It’s all about the money

46. … to hack you …

48. Buy botnet for $110

49. How much it cost to be an ‘internal user’

50. 100% Anti-virus non detection guarantee

51. But the credit cards were protected

52. R U S S I A N H A C K E R S M O V E D R U B L E R AT E
W I T H M A LWA R E
http://www.bloomberg.com/news/articles/2016-02-08/russian-hackers-moved-currency-rate-with-malware-group-ib-says

53. I T I S I N T H E B I L L I O N S
• The real criminals are running highly professional
companies, with high quality software Development,
Testing, QA, AB testing, etc…

54. N E W G E N E R AT I O N
O F A P P L I C AT I O N
S E C U R I T Y
T H I N K I N G

55. • TDD
• Docker
• Test Automation
• Static Analysis
• cleaver Fuzzing
• JIRA Risk workflows
• Kanban
• micro web services visualization, and
• ELK

56. W E H AV E S O L U T I O N S

57. O WA S P ! ! ! !

58. T I P S F O R B U I L D I N G A M O D E R N
S E C U R I T Y E N G I N E E R I N G O R G A N I Z AT I O N
• https://georgianpartners.com/tips-for-building-a-modern-security-
engineering-organization

59. H O W T O B U I L D S E C U R E W E B
A P P L I C AT I O N
• http://blog.knoldus.com/2016/02/03/how-to-build-secure-web-
application/

60. R E A L W O R L D M U TAT I O N T E S T I N G
• http://pitest.org/

61. S E C U R I T Y D E V E L O P M E N T L I F E C Y C L E
• https://www.microsoft.com/en-us/sdl/process/design.aspx

62. S P O T I F Y E N G I N E E R I N G C U LT U R E -
PA R T 1
• https://labs.spotify.com/2014/03/27/spotify-engineering-culture-
part-1/
• https://spotifylabscom.files.wordpress.com/2014/03/spotify-
engineering-culture-part1.jpeg

63. S P O T I F Y E N G I N E E R I N G C U LT U R E -
PA R T 2
• https://labs.spotify.com/2014/09/20/spotify-engineering-culture-
part-2/
• https://spotifylabscom.files.wordpress.com/2014/09/spotify-
engineering-culture-part2.jpeg

64. F I N A L T H O U G H T S

65. U N W R I T T E N R U L E S O F A P I S
“Every API is destined to be connected to the internet”

66. U N W R I T T E N R U L E S O F A P I S
“All API data wants to be exposed in a Web Page”

67. “Would you fly in a plane that has the code quality
of your APIs”

68. Thanks, any questions?