Рано или поздно любая компания задумывается как о безопасности своего продукта, так и внутренней безопасности, и это неизбежно ведет к выстраиванию security-процессов, стандартов, требований и политик. Этот процесс довольно сложный и трудоемкий, требующий определенной зрелости компании и слаженной работы всех сотрудников. Мы хотели бы рассказать о своем опыте создания security-культуры компании Wrike, в том числе с помощью продукта, который мы делаем. Также мы поделимся опытом решения реальных проблем безопасности, с которыми сталкиваемся сами или наши клиенты.

1. Secure SDLC or Security Culture
to be or not to be
29/04/2016
DCG #7812
St. Pete
by
@wrike

2. SDLC, Agile, Waterfall, Chaos…
Defcon Russia (DCG #7812) 2
- Review of business requirements
- Review of architecture and design
- Threat modeling
- Source code review
- Automatic security testing
- Manual assessment
- Periodical penetration testing
- Planning, Reporting
- Routine
- etc.

3. SDLC, Agile, Waterfall, Chaos… Result?!
Defcon Russia (DCG #7812) 3
• Requirements from different places
• Deprecated and deep-seated architecture
• Various threats, impossible to be
managed
• Multiple entry points
• Various development teams
• No standards and processes
• No tools
• Continuous delivery
• Business requires certifications…

4. Show must go on…
• Deep-sea diving into vulnerabilities
• Detecting
• Explanation and Trainings
• Fixing and review
• Automation: tools, methodologies, technics
• Continuous communication with development teams
• Become the informal part of development team
• Define simple rules and processes
• Flexible (agile) integration into the process
• Public standards and requirements inculcation
• Talking about regulators and external certifications

5. Requirement Evaluation
• Internal Security Standards and
Requirements
• Customers Requirements (many and
various)
• International Requirements as PCI DSS,
CSA, ISO, SOC, HIPAA, etc.
• Best Security Practices including OWASP,
Security Features and Functionality

6. Business vs Security
• Integration with external services and vendors
• Internal backend services
• Internal plans and evolution of the product
• New employees and extremely high extension
• Different business departments: Analytics, Marketing, Sales,
Customer Support, HR, Development, etc.

7. Threat Modeling and Security Cases
Custom workflows

8. Security Issues or Risks

9. Security Issues or Risks

10. Security Issues or Risks

11. Implementation Stage
• Because the development process is always on
• Developers are very serious and strange people
• Many teams, their size, knowledge and expertize
• Many languages, frameworks and tools
• Automation source code review
• Auto testing via tools and auto tests

12. Security Testing and Assessment

13. Risk Management
It is a big deal and we are in progress to establish it basing on our
current experience and world best practices.

14. Why Culture is Important
• Culture is an environment of user behavior
• It is about users doing things right in the first place
• When users do things right, there are fewer incidents
• Fewer incidents result in fewer costs
• Incident prevention saves money
• Strong security culture generally implies a more operationally
efficient environment as well
• Avoid to suffer death by 1,000 Cuts

15. Where is Security Culture?

16. How Security is Perceived

17. Typically Think Security Does
• Stop employees from doing dumb things
• Put out the fires
• Consulted as an afterthought
• Stupid Security Policies and Procedures
• Approve the access, check a box, etc.
• Punishment and penalties
• Makes recommendations that they are forced to justify

18. Strong Security Culture
• Proactively involved in decision making process
• Consulted proactively on new efforts to ensure security is integrated
into the efforts
• Consultation for ongoing efforts
• Security has the authority to stop activities as appropriate
• Employees act securely by default
• Security is ubiquitous to actions
• They are “aware”
• People do not actively attempt to bypass security countermeasures

19. Strong Security Culture
• Awareness Programs
• Trainings
• Lessons and Exercises
• Instructions and Guidelines
• Best practices
• Knowledge checks and funny testing
• Common knowledge -> common sense

20. Real cases and interesting
facts

21. External Security Researchers
Many messages with similar and/or fake security issues

22. Sessionless Application and Race Condition
• Session-less is preferable nowadays:
• Scalability in many dimensions - sharing by user, geography, etc.
• Saves server resources
• Easy to maintain, caching can be applied at different layers
• Better availability
• No need to recover after support and maintenance
• But:
• Having to keep some user related information in cookies
• Requires more coding and understanding

23. Sessionless Application and Race Condition
Never mix Session and Sessionless states, otherwise race condition as a
result, especially when integration with external services is going on:
• Session in Application Server are created automatically.
• Spring framework suggests to use SpringContext.
• ThreadLocal context is never cleaned up.
• All information in scope of the current application is managed and controlled
properly, but what to do with 3rd party data as authentication details?
Such issues are hard to be found.

24. Thank you!