Рано или поздно любая компания задумывается как о безопасности своего продукта, так и внутренней безопасности, и это неизбежно ведет к выстраиванию security-процессов, стандартов, требований и политик. Этот процесс довольно сложный и трудоемкий, требующий определенной зрелости компании и слаженной работы всех сотрудников. Мы хотели бы рассказать о своем опыте создания security-культуры компании Wrike, в том числе с помощью продукта, который мы делаем. Также мы поделимся опытом решения реальных проблем безопасности, с которыми сталкиваемся сами или наши клиенты.
Unlocking the Future of AI Agents with Large Language Models
Dmitriy Desyatkov "Secure SDLC or Security Culture to be or not to be"
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.
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
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
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
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.
Создание полноценного, работающего и правильного процесса безопасности, интегрированного в корпоративный SDLC – это всегда сложно, труднодосягаемо и бла-бла-бла. Надо делать все вовремя и чем раньше, чем лучше, и тогда все будет безопасно, качественно, стабильно и вообще круто.
И вроде бы все красиво в теории, но когда дело доходит до практики, то возникает много НО и проблем. Безопасность становится бутылочным горлышком во многих процесса, ставит палки в колеса разработке, новым фичам и функциональности…
Во всем таком хаосе процессы строятся очень долго и невозможно делать что-то без определенной зрелости компании, и не совсем понятно как эту чертову теорию применить к реальной практике, как сделать продукт безопасным, удовлетворять всем требованиям (внешним и внутренним), получить все сертификации, построить команду, процессы, и прочее.
Зачем требования если о них никто не знает и они всегда нарушаются?!
Мы попытались структурировать требования таким образом, чтобы они наглядно показывали что-где, и в
И тут важно обсуждать детали с бизнесом, договориться с ним что безопасность это неотъемлемая часть процессов в компании
Зачем требования если о них никто не знает и они всегда нарушаются?!
Существует большое количество разнообразных культур: где все доступно, где все полностью запрещено. Но типичная культура компании на начальных этапах выглядит так:
Badges are a nuisance
Everyone loves to talk and complain about their work
Restaurants/Pubs are a great place to catch up on work related issues
People write down passwords
Nobody stops strangers
Computers are left open while unattended
Suffer Death by 1,000 Cuts
И конечно же постоянно возникают вопросы: Нужна ли безопасность?
Поэтому безопасность не должна всегда говорить НЕТ, она должна прислушиваться к тому, что нужно компании, и понять как это можно добиться.
Поэтому безопасность не должна всегда говорить НЕТ, она должна прислушиваться к тому, что нужно компании, и понять как это можно добиться.