Designing Secure Cloud-based Web and Mobile Applications · 2017-10-25 · SOA, Microservices...
Transcript of Designing Secure Cloud-based Web and Mobile Applications · 2017-10-25 · SOA, Microservices...
Designing Secure Cloud-based Web and Mobile Applications
Farshad Abasi / Mirai Security Inc.
About Me
⊡ Farshad Abasi□ Based in: Vancouver, BC, Canada□ Co-founder: Mirai Security Inc.□ CTO/CISO: Machool Technologies□ Instructor: British Columbia Institute of
Technology (BCIT)□ News correspondent: CFAX AM1070 (Victoria)□ Board member: BSides Vancouver / MARS□ Avid music fan!
Introduction
⊡ Winds of Change⊡ Security by Design Principles (OWASP)⊡ Cloud Security□ Top Cloud Computing Threats (Cloud Security Alliance)□ Cloud Controls Matrix (Cloud Security Alliance)□ Container Security
⊡ API Security⊡ Web Channel Security (OWASP Top 10)⊡ Mobile Channel Security (OWASP Mobile Top 10)⊡ Q&A
Winds of Change
Winds of Change
Digital Transformation⊡ Consumers demand anytime, any-device, anywhere access⊡ Affects many aspects of the business and related processes⊡ Requires agility, adoption of new technologies, and re-
architecting existing applications and services⊡ APIs and Cloud related technologies are key ingredients
□ VMs, Containers□ SOA, Microservices
⊡ Impact to existing policies, standards, tools, teams, processes
⊡ Great deal of pressure ahead due to massive digital disruption
Winds of Change
⊡ Infrastructure is moving to the cloud and being deployed as code⊡ Applications are being re-architected as
microservices and hosted in containers⊡ Digital transformation is resulting in more
web and mobile applications, typically served from the cloud
AWS
AzureGoogle IBM
Security By Design Principles(By OWASP)
Security By Design Principles
OWASP’s Security by Design Principles⊡ Guidance to produce secure apps by design⊡ Before determining the controls to use:
□ Classify assets first□ Consider the most likely attackers
⊡ Consider each of the C, I, A when building controls□ Will assist in producing robust controls
⊡ Security Architecture □ Just as important as architecture in the real world□ Must account for extreme conditions□ Fundamental pillars
Security By Design Principles
1. Minimize attack surface area2. Establish secure defaults3. Principle of Least privilege4. Principle of Defense in depth5. Fail securely6. Don’t trust services7. Separation of duties8. Avoid security by obscurity9. Keep security simple10. Fix security issues correctly
Security By D
esign Principles
Cloud Security
“Cloud Security
“a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g.,
networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or
service provider interaction.”- SP 800-145, The NIST Definition of Cloud Computing
Cloud Security
⊡ Cloud computing requires a workload isolation mechanism□ Physical separation (aka Bare-metal Cloud)
■ Addresses covert channels & defects in H/W protection mechanisms
□ Virtualization (aka Hardware Virtualization)■ Used to provide IaaS
■ Vulnerabilities related to CPU or hypervisor can have impact
□ Containerization (aka OS-level virtualization)■ Used to deliver CaaS or PaaS
□ Multi-user accounts within a single application■ In other words: SaaS
Cloud Security
PaaS/CaaS
IaaS
Bare-metal
SaaS
MO
RE
CO
NTR
OL
LES
S C
ON
TRO
L
INFRASTRUCTUREARCHITECTS/ADMINS
APPLICATIONARCHITECTS/DEVELOPERS
END-USERS
Different Cloud Computing Models Based on Workload Isolation
Cloud Security
⊡ Security concerns fall into 2 categories□ Cloud Provider (SaaS, PaaS, IaaS) must ensure:■ Infrastructure is secure■ Clients’ data and applications are protected
□ Customers must:■ Take measures to fortify the application■ Use strong authentication and additional security controls
⊡ Shared Responsibility!⊡ General Security Concerns:□ Multi-tenancy□ Regulatory and Compliance□ Unauthorized Shadow IT□ Intellectual Property Loss⊡ Important: Key Management & Access Control
Cloud Security: Top Cloud Computing Threats
(by Cloud Security Alliance)
Cloud Security
CSA’s Treacherous 12: Top Cloud Computing Threats1. Data Breaches□ Shared resources, cloud provider personnel, their 3rd party partners
2. Weak Identity, Credential and Access Management□ Failure to use MFA, weak passwords, lack scalable IAM and key rotation
3. Insecure APIs□ Expose sensitive assets to the outside and target of heavy attacks
4. System and Application Vulnerabilities□ Shared memory & resources add new attack surface due to multitenancy
5. Account Hijacking□ Effect is amplified, allowing access to cloud services and data
6. Malicious Insiders□ Employees (e.g. sys admins) can have access to sensitive systems/data
Cloud Security
7. Advanced Persistent Threats (APTs)□ Establish a foothold in the infrastructure and remain stealth
8. Data Loss□ May not be malicious (e.g. accidental deletion by cloud provider)
9. Insufficient Due Diligence□ Rushing to adopt may have financial, legal, and compliance risks
10. Abuse and Nefarious Use of Cloud Services□ Can be used for DDoS, spam, phishing campaigns, crypto mining,
etc. via payment instrument fraud and misuse of services/resources11. Denial of Service□ Targeted services in the cloud can take away resources from others
12. Shared Technology Vulnerabilities□ Underlying infrastructure, platform, or application is shared
Cloud Security: Cloud Controls Matrix
(by Cloud Security Alliance)
Cloud Security: CCM
Cloud Security: Containers
Cloud Security
Containerization ⊡ aka OS-Level Virtualization⊡ Multiple isolated user-space
instances sharing a kernel⊡ Each instance = a container
(aka partition, virtualization engine (VE) or jail (e.g. FreeBSD jail or chroot jail)
⊡ Seems like a regular machine from the inside
Cloud Security: Containers
⊡ Containerization□ Containers share the same OS kernel
■ Cannot use containers with different operating systems
□ Faster, lightweight, more portable, scale more efficiently■ No H/W emulation
□ Do not provide the same level of isolation as virtualization
⊡ Virtualization□ Mature with an extensive ecosystem
□ Allows for mixed kernels on the same platform
□ Host emulates the hardware provided to the VM■ looks like it is running on separate hardware
□ Hypervisor is the security boundary: More secure
Cloud Security: Containers
Containers share OS kernel and (possibly) binaries and libraries
Cloud Security: Containers
⊡ Containers are very useful□ help ease software management
⊡ Work is being done to address security□ e.g. implementation of user namespaces
⊡ Should be used with caution□ processes in the container should not be given privileged
access □ good for deploying apps that are trusted (e.g. same
vendor)
□ other mechanisms such as SELinux, seccomp, AppArmor, and separate user accounts should be used in conjunction
Cloud Security: Containers
⊡ Group containers on a given VM based classic segregation principles□ Use a risk based approach, consider impact and likelihood
⊡ Services should be run as unprivileged
⊡ Privilege should be dropped as soon as not needed
⊡ Treat root inside a container as if it is root outside the container
⊡ Only run containers from trusted parties
⊡ Follow a layered defense approach□ Use AppArmor or SELinux
Cloud Security: Containers
⊡ Standardize and verify hardened host OS
⊡ Scan containers for vulnerabilities□ OSS modules, licensing, malware, correct configuration
⊡ Measure containers and sign□ Analyze, sandbox, build profile
□ Confirm signatures at boot: Confirm host OS integrity
⊡ Monitor and detect anomalous behavior□ Alert, log, or prevent
⊡ Analyze usage logs to:□ Identify weaknesses, adapt patterns
□ Share learning across different instances
API Security
API Security
⊡ Maintain end-to-end trust across the entire journey
⊡ Ensure authZ is enforced at the right place with the right level of granularity
⊡ Group your APIs to apply configurable security policies consistently
⊡ Don’t forget to log, monitor and detect
⊡ Follow a defense-in-depth strategy and add security at all layers
Web Channel Security(OWASP Top 10 - 2017)
Web Delivery Channel Security
A1 Injection A2 Broken
Authentication and Session Management
A3 Cross-Site Scripting (XSS)
A4 Broken Access Control
(As it was in 2004)
A5 Security Misconfiguration
A6 Sensitive Data Exposure
A7 Insufficient Attack
Protection (NEW)
A8 Cross-Site Request
Forgery (CSRF)
A9 Using Components with Known
Vulnerabilities
A10 Under protected APIs
(NEW)
OWASP Top 10 Threats (2017)
Mobile Channel Security(OWASP Mobile Top 10)
Mobile Delivery Channel Security
OWASP Mobile Top 10 Threats
M1: Improper Platform Usage
M2: Insecure Data Storage
M3: Insecure Communication
M4: Insecure Authentication
M5: Insufficient Cryptography
M6: Insecure Authorization
M7: Client Code Quality
M8: Code Tampering
M9: Reverse Engineering
M10: Extraneous Functionality
Q&AContact: Farshad Abasi