This talk will help you, as a decision maker or architect, to understand the risks of migrating a thick client or traditional web application to the modern web. In this talk I’ll give you tools and techniques to make the migration to the modern web painless and secure so you can mitigate common pitfalls without having to make the mistakes first. I’ll be doing demos, and telling lots of stories throughout. Making some good architectural decisions up front can help you: - Minimize the risk of data breach - Protect your user’s privacy - Make security choices easy the easy default for your developers - Understand the cloud security model - Create defaults, policies, wrappers, and guidance for developers - Detect when developers have bypassed security controls

2. About Security Innovation
• Authority in Software Security
• 18+ years research on software vulnerabilities
• Security testing methodology adopted by SAP,
Symantec, Microsoft and McAfee
• Authors of 18 books
• Helping organizations minimize risk
• Assessment: Show me the gaps
• Education: Guide me to the right decisions
• Standards: Set goals and make it easy and natural
• Tech-enabled services for both breadth and depth

4. Simple!

5. Just think about…

6. Authentication

7. Authorization

8. Scale

9. DDOS

10. SQLi

11. Architecture

12. Data Storage

13. Data Transit

14. Passwords

15. Load balancing

16. CDNs

17. GDPR

18. Data Warehousing

19. Compliance

20. Cookie Policies

21. Intranet/Internet

22. User Education

23. Frameworks

24. Futureproofing

25. Browser compat

26. … and literally 100s of
other things

27. Never mind!
I’m leaving this piece of
crap app as an installer
from the 90’s

28. No, No, we will do this, together, securely.
We will make a plan and execute it!

29. Break it down
• Migrating to modern web technologies
is analogous to building from scratch
• But you get great use, abuse,
mis-use, and dis-use cases
• This gives you a great roadmap of
what you want to build
• Don’t duplicate the old app, build
something better
• Use good defaults, policies, wrappers,
guidance to build securely and quickly

30. The tale of two cities apps
App #1 – Colin Powell
“Help! We have a great
architect, but don’t know about
security. We haven’t written a
line of code, and need guidance
on what to look out for.”
App #2 – Leeroy Jenkins!
“Help! We ship in three weeks!
Everything’s done, but our CISO
says we need a security audit
before we launch. Can you push
this through?”

31. My high-level roadmap

32. Minimizing the risk of
a data breach

33. They can’t steal what you don’t have
• Minimizing the risk of a data
breach starts with a
commitment to privacy
• Set goals for data
collection
• Gather only what data is
necessary
• Create a clear and
concise data
classification policy

34. But what about Machine Learning?!
“If I collect all the data now,
we’ll give it to the Data
Scientists and they’ll give
us insights”
More data == more risk

35. Data Classification Domains
Restricted
• Access – Only by limited individuals
• Consequences – termination, possibly legal
• Example – Financial data, Healthcare data
Highly Confidential
• Access - Individuals, Groups, or Senior Management and above
• Consequences – Investigation, reprimand, or termination
• Example – Sensitive IP, Client Lists, Billing Details
Confidential
• Access – Relevant or related teams
• Consequences – HR reprimand
• Example – Any internal company information
Unrestricted
• Access - Public
• Consequences –N/A
• Example- Public information
There is no universally accepted data classification tiers, these are examples

36. Make privacy a priority
• Privacy is a market differentiator
• Agree that user privacy is important
• Set goals for data collection
• Set a high bar for new trackers
• Gather only necessary data
Again, More data == more risk

37. Developing Secure Code
Make this
as easy as possible,
Like falling into a
“Pit of success”
Training
•Identify good/bad
patterns early
Assessment
•Verify
•Detect
Automation
•Infrastructure as Code
•Security as Code

38. Training
• Our goals in training are twofold
• Help the team develop a sense of what is right
• Give them the ability to identify what doesn’t feel right
• Security ”Code Smells”
• Recurring coding patterns that are indicative of security
weakness and can potentially lead to security breaches
Learning/Following Doing/Practice Leading/Teaching

39. Automation
The developers are taking over
• Security/Infrastructure as Code
• Ensures the same issue doesn’t
get into production again
• Automate monotonous,
problematic tasks
Write Code
Code review
Check into repository
Perform unit and
integration tests
Find issues in
dev/test/production
Remediate issues in
code

40. Assessment &
Detection
• Testing is the backstop of good
training, design, and automation
• Detect when developers have
bypassed security guidance
• Rollback
• Remediate
• Train
• Vulnerabilities in…
• Deployment/Infrastructure
• Code
• Architecture
• Process

41. Defaults
• Creating a system in which it is difficult to
make mistakes is one of the best
investments you can make
• Provide developers:
• Libraries that protect them
• Frameworks that include security controls
• Templating engines that minimize injection
issues
• Defaults that follow best practices
• Wrappers for common libraries protect from
mistakes

42. Where are we and what
do we look out for?

46. Now we have this?!

47. How did we get here?

48. We want to sell stuff!
• These literally hooked
something like perl to a
web interface
• Maybe you got a database
or some flat text files
• Security was unknown

49. We can do so
much more
Exceptionally Dynamic
Location aware
data from multiple sources
Advertising
User Tracking
SSO and more
Much greater code reuse
Libraries and frameworks
Templates
More clients connect to same API
Web
iOS/Android
Desktop
API
iOS
Android
WebDesktop
Integrations

50. API Based issues
JSON/XML injection Authorization Attacks
IDOR - Insecure Direct Object
Reference
Exposing Sensitive Data Client Side Data
filtering
Just because you can’t see it, doesn’t mean it’s protected

51. Authorization Attacks
IDOR – Insecure Direct Object Reference

52. Authorization Attacks
Exposing Sensitive Data & Client-Side Data Filtering

53. JSON/XML Injection and Manipulation
• Inject data, manipulate logic, or execute code
• User: JoeBasirico
{
"action":"create",
"user":"JoeBasirico",
"pass":"$3cre7"
}
Creates a user named JoeBasirico

54. JSON/XML Injection and Manipulation
• Inject data, manipulate logic, or execute code
• User: JoeBasirico", "account":”administrator
{
"action":"create",
"user":"JoeBasirico", "account":"administrator",
"pass":"$3cre7"
}
Creates an Administrator named JoeBasirico

55. Don’t expose your data store
https://blog.shodan.io/its-the-data-stupid/

57. Always Force TLS
• It’s 2020, TLS is free, easy, fast. There is no reason not to
• Redirect to TLS v 1.2 or greater by default.
• Do not serve data over http or SSL

58. APIs and Modern WebApps are powerful!
• They can’t steal what you don’t collect
• Make an early commitment to security and privacy
• Let that drive your decision making from here on out
• Create secure defaults, libraries, wrappers and guidance for your
developers.
• Make it difficult to make decisiosn
• Make it easy to fall into a pit of success
• Use automation to ”learn” from your mistakes
• Detect when controls are bypassed, use it as a learning opportunity
SI Community - https://community.securityinnovation.com/

59. Questions? Thoughts?
jbasirico@securityinnovation.com
linkedin.com/in/joebasirico
twitter.com/joespikey
Joe Basirico
Security Innovation
SVP Engineering