CSA - Nsc42 - London chapter keynote - cloud transformation security challenges
•Download as PPTX, PDF•
0 likes•132 views
Cloud security alliance Annual meeting London - The presentation covers cloud transformation challenges and patterns to facilitate transformations
Recommended
Recommended
More Related Content
What's hot
What's hot (12)
Similar to CSA - Nsc42 - London chapter keynote - cloud transformation security challenges
Similar to CSA - Nsc42 - London chapter keynote - cloud transformation security challenges (20)
More from NSC42 Ltd
More from NSC42 Ltd (9)
Recently uploaded
Recently uploaded (20)
CSA - Nsc42 - London chapter keynote - cloud transformation security challenges
- 1. CloudTransformation Challenges For CSA Annual Meetup @FraSEC42 Francesco Cipollone
- 2. Our History Helping UK Companies We have been helping UK organization in multiple sectors overcome security challenges since 2013 Development of Cybersecurity Strategies Audit and assessment of cloud transformation Architecture support and production of artifacts DevSecOps support
- 3. Disclaimer: the pictures and the format in this presentation are under license to NSC42 Ltd Our Agenda About the author and company Setting the context Regulation Shared Responsibilities Identities and Access controls Patterns Processes review Caveat/Pitfalls Take Away The Challenges Q&A
- 4. www.nsc42.co.uk About the Author 4 Francesco Cipollone Founder – NSC42 LTD Francesco is an accomplished, motivated and versatile Security Professional with several years of experience in the Cyber security landscape. He helps organizations achieve strategic security goals with a driven and pragmatic approach. Francesco is a founder of NSC42 Ltd and previously co-founder of Technet SrL. …he is known to have Impostor syndrome Definition - Impostor syndrome s a psychological pattern in which an individual doubts their accomplishments and has a persistent internalized fear of being exposed as a "fraud". FC-LinkedIn E-Mail Website Articles NSC42 LinkedIn Ultimately security is a hard field and we are supposed to know a lot about a bit of everything the key element is collaboration and sharing knowledge @FraSEC42
- 5. www.nsc42.co.uk Context and challenges 5 Setting the context and challenges: - Management - Disruption and strategy - Security as part of the cloud journey - Skills shortages - Architecture patterns: - don’t reinvent the wheel - don’t take on-premises into the cloud
- 6. www.nsc42.co.uk The Challenges 6 In a cloud transformation, consider the following key elements: - Shared responsibility model - Regulation - Identities and Access management - Different (Security) Patterns Other aspects: - New work methodologies (DevOPS and Microservices ) - Risk management/incident management
- 7. www.nsc42.co.uk Shared Responsibility Model 7 Understand Shared Responsibility model: - Who is responsible for what - Trust level and regulation - Traditional controls vs cloud controls Customer Application & Content Network Security Identity & Access Control Operating System/ Platform Data Encryption The Customer Customer Defines controls security IN Cloud Customer takes care of the security OF Cloud Physical Infrastructure Network Infrastructure Virtualization Layer Cloud platform
- 8. www.nsc42.co.uk Regulation 8 Understand Regulation and how will it impact the transformation: - Not all regulation are up to speed - Hybrid Environment: Roles and responsibilities - Adapt the mandated control to the cloud - Refer to existing patterns/control set (e.g. CSA CCM…) - Refer to cloud based standards (ISO27017/18, CSA CCM…)
- 9. www.nsc42.co.uk Patterns 9 I’d like to discuss some of the pattern that did stand out in recent transformations - Type: Hybrid vs cloud only - Scaffolding - Traditional vs cloud controls - Logging and monitoring - Identity and access management Patterns for the cloud are different from traditional
- 10. www.nsc42.co.uk Pattern – Scaffolding 10 Things to consider: - What works in the cloud provider - Shared services vs production - Access control and MFA - Isolation and RBAC AWSAzure
- 11. www.nsc42.co.uk Pattern – Firewalls and access control 11 Things to consider: - AWS & Azure are different - Adapt patterns - Consider cloud native controls AWSAzure
- 12. www.nsc42.co.uk Pattern – Logging, cascade architecture and Monitoring 12 Things to consider: - Multiple Type: Instance vs Platform - Access to Logs - Cascading architecture - isolation - Automated incident response Prj account Log Central log SOC Dev Test Prod Application Logs
- 13. www.nsc42.co.uk Pattern – Identity and access management 13 Recommendations: • Isolate identity store • Federation • Roles and Access control • API secret vs authentication
- 14. www.nsc42.co.uk Caveats/Pitfalls 14 Cloud transformations can be a treacherous journey especially for security professionals. Watch out for the common pitfalls - Security shall be an enabler not a blocker - Security and other team would require upskilling - Solid foundation enables smooth sailing of cloud projects Cloud is just someone else's PC
- 15. www.nsc42.co.uk Conclusions 15 Wrapping up, we’ve discussed - Cloud transformations planning - Seek support of management - Consider skill shortage - New Architecture/methodologies Conclusions conslusions conclusions
- 16. www.nsc42.co.uk Take Away 16 Cloud transformations can be a treacherous journey especially for security professionals: - Decisions supported by Strategy - Solid Foundation (Security) - Skill shortage: be prepared to learn - Native cloud controls! Use them - Patterns and arch - Automation
- 18. www.nsc42.co.uk Contacts 18 Get in touch: https://uk.linkedin.com/in/fracipo Francesco.cipollone (@) nsc42.co.uk www.nsc42.co.uk Thank you @FraSEC42
Editor's Notes
- Intro Thank you for being here and a thanks to the CSA local chapter in London for organizing this event Today I’m going to take you on the journey of cloud transformation and the challenges it implies from a security prospective. As security professionals we are facing an unique and exciting challenge but also an opportunity to participate and distill security in the foundation cloud architecture. I strongly encourage everybody to participate in the discussion that will follow and help your fellow security professional in improving the security in the cloud As a note this presentation this presentation does represent my personal opinion and does not reflect the view of my organization or any of NSC42 customers
- Background of NSC42 Ltd
- Agenda for today - About the author Setting the context The challenges: Shared responsibility /Access controls/Patterns/Processes review New Methodologies Caveats/Pitfalls Take away Q&A
- Presenter Background I’m the of Founder – NSC42 LTD a security consultancy based in UK I’m a consultant that helps organization migrate safely and securely to the cloud. I’m the founder of NSC42 Ltd and previously co-founder of Technet SrL a teaching and consultancy firm in Italy. I’m known to have Impostor syndrome The Impostor syndrome is a very interesting effect of modern security professionals. As security professionals we’re asked to know a lot about everything. But security is hard and the knowledge is vast…so I’ll try to be the guiding voice in the discussion but ultimately I’m a security bloke that is trying to share some knowledge with my fellow peers and help shape the future of information security together. I’d like to mention the work of Stu Hirst: https://www.youtube.com/watch?v=ZPb2PlIK8-o
- Setting the context Successful Cloud transformation usually start with a strong sponsorship from upper management. Cloud transformation are a revolution in process procedures, people, and they tend to last quite a bit of time for the transformation to transition in BAU. Whenever the management expects rapid transformations or does not pan out a clear strategy the cloud transformation usually turns out in a half cooked datacenter When Security get left at the end of a transformation, the remediation bill ends up being quite hefty (technical debt/backlog) Cloud transformations are hard as they present unique challenges to traditional organization. We will explore some of the challenges. Skills shortages: consider the skills in the organization: upskill or hire? what is the market looking like? Architecture patterns: consider new patterns, blueprints from cloud provider and don’t lift and shift the cloud datacenter
- In a cloud transformation the consider the following key elements: Shared responsibility model -> who is responsible for what Regulation -> what to do in cloud environment and who is responsible for what Identities and Access management -> roles and responsibilities Different (Security) Patterns -> change the traditional patterns and adjust The following will take a whole different talk but I’ll mention for completeness New work methodologies (DevOPS and Micoservices ) – Pipeline and microservice are not a must but they integrate nicely in the cloud environment Risk management/incident management -> improvements
- Shared Responsibility model The shared responsibility model will determine who will do what in a cloud environment. The shall be a level of understanding of what is the cloud provider doing for you as customer (cloud is not secure, is just another datacenter) and what you have to do to secure the cloud (e.g. identity, key management, encryption etc…) The organization shall rely the cloud provider and trust it to a comfortable level but always understand who is responsible for what. Certain controls and process will be better implemented by a cloud provider than an individual customer will be able to implement (with the odd exceptions) Any kind of traditional control applied to the cloud (network traffic analyses) shall be the result of a risk assessment. Forcing traditional security controls into the cloud might result ineffective and expensive.
- Understand Regulation and how will it impact the transformation: Some regulations are outdated and are not immediately applicable to the cloud Understand who is responsible for what in the new hybrid environment -> from a regulation standpoint the cloud provider will be responsible of certain process and controls (e.g. physical controls) but the user remains ultimately responsible for the governance and due diligence (verify certifications and controls) Adapt the mandated control to the cloud -> certain controls and regulation needs some work and interpretation to adapt to the cloud (e.g. ISO 27001) but they are generic enough to be open for interpretation. Today most of the standards have been updated for the cloud (e.g. 270017/18 PCI-DSS 3.2 etc…) Refer to existing patterns/control set (e.g. CSA CCM…) and reference architecture (ISC, AWS Blueprint, Azure Blueprints) Leverage cloud based regulation (ISO27017/18, CSA CCM…)
- I’d like to discuss some of the pattern that did stand out in recent transformations Scaffolding (permissions, Accounts, Isolations) Traditional vs native controls considerations on Logging and monitoring Identity and access management References: https://cloudblogs.microsoft.com/microsoftsecure/2018/06/06/cybersecurity-reference-architecture-security-for-a-hybrid-enterprise/ https://aws.amazon.com/security/security-resources/ https://d1.awsstatic.com/whitepapers/Security/AWS_Security_Best_Practices.pdf https://d1.awsstatic.com/whitepapers/AWS_CAF_Security_Perspective.pdf https://d1.awsstatic.com/whitepapers/architecture/AWS-Security-Pillar.pdf
- Things to consider: AWS and Azure work in different way on the subscription Isolate Shared service account and use managing vs managed patterns (PCI pattern) Logical hierarchy enables isolation and delegation of roles (RBAC) Access control and MFA Link the division of accounts to the billing but also use tagging References: AWS: https://aws.amazon.com/answers/account-management/aws-multi-account-security-strategy/ Azure: https://docs.microsoft.com/en-us/azure/architecture/cloud-adoption/appendix/azure-scaffold
- Things to consider: - AWS and Azure work in slightly different way for NVA Network Virtual Appliance (peering) DMZ and other on-prem. pattern don’t always make sense Access control using the native controls (WAF, NSG) NVA enable a smoother transition to the cloud (knowledge, ruleset, management) but they come at a cost (complexity, licenses etc…) References: https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/dmz/secure-vnet-hybrid https://aws.amazon.com/blogs/awsforsap/vpc-subnet-zoning-patterns-for-sap-on-aws-part-2-network-zoning/ https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html
- Things to consider: Log the VM activities but most important the cloud activity Log Platform activity (management, API interaction etc..) Centralize and pre-process logs Control access to buckets (read write vs Read) Use cloud services as much as possible as they are integrated with the cloud fabric Cascading architecture enables segregation of logs as well as escalation path In advanced level of maturity leverage on automated incident response (e.g. Lambda) – different talk Pattern reference: https://docs.aws.amazon.com/solutions/latest/centralized-logging/architecture.html https://aws.amazon.com/blogs/architecture/central-logging-in-multi-account-environments/ https://aws.amazon.com/quickstart/architecture/compliance-cis-benchmark/ https://docs.microsoft.com/en-us/azure/security/azure-log-audit
- Recommendations: Isolate identity store but centralize the accounts in order to simplify account review/JML process/ Federation frontend helps isolate the identity store and accounts but at the same time integrate the identity with different identity frontends (e.g. AWS IAM) Perform RBAC analysis and identity roles and permissions -> create a matrix of roles and what each role has access to Food for thought (takes too much time to discuss in one session) API and other automation shall use authentication against a key vault to retrieve secret key -> this enable logging and segregation. The identity key shall be stored in some credential store (key vault or secret vault). The API shall authenticate against the key vault to retrieve key (usually with a javascript or similar). References https://docs.microsoft.com/en-us/azure/role-based-access-control/role-assignments-portal https://docs.microsoft.com/en-us/azure/active-directory/b2b/faq https://docs.microsoft.com/en-gb/azure/active-directory-b2c/ https://aws.amazon.com/documentation/iam/
- Cloud transformations can be a treacherous journey especially for security professionals. Watch out for the common pitfalls Security shall enable the business to thrive and not be consider a blocker Security imposed to cloud transformation with just policies/standards and antiquated patterns. -> this results in security as blocker and slow down the implementation Involve security as after thought -> this results to rush decisions, bolt on controls, and possible re-development of part of the application. Having a strong foundation (security) enables smooth sailing of new cloud projects developed in and on the cloud
- Wrapping up what we’ve discussed Cloud transformation requires careful planning and involved in security Seek support of management as cloud transformation tend to involve the entire organization Consider skill shortage and how to recruit/upskill the team (not just security) Patterns are different consider the use of native cloud pattern and cloud controls
- Security decisions be supported by a solid strategy. Without a strategy the security decision (e.g. tools) will not address long term architecture vision Solid Foundation (Security) architecture enables fast delivery of products. Spend time at the beginning and re-use controls/tools. Well thought trough architecture withstand time and enable the setup of working methodologies like agile and dev-ops without major disruption of the security posture Security shall be part of the design from the start this enable security by design, more efficient use of time (no re-work) and facilitate the integration of security controls (instead of patch them at the end). Security professional shall be flexible and use the cloud fabric/tools this will result in an effective and cost efficient implementation of security control (simple design) Resource security team to address new challenges/demands to the new challenges (cloud) and the velocity of new demands (dev-ops) Automate security and code testing leave the boring job to machines
- Q&A
- Contacts