View
4
Download
0
Category
Preview:
Citation preview
Cloud Security – Implementation Reality
Hoo Chuan Wei CISSP, CISA, CFE, BCCE Technical Advisor, (ISC)2 APAC Executive Security Advisor, IBM Security
#CLOUDSEC
Cloud is HERE to STAY
2
SETTING THE SCENE
ISC2
This ?...Clarity
• A new paradigm (secure if built correctly) • Cost saving • Business differentiator • Following the trend… • Security
• Last thing on anyone’s mind
Good thing you have these experts around • Wake up call • Highlight the other side of the coin • Get REAL!!! (certifications)
3
WHERE ARE THE SECURITY FOLKS
ISC2
Guidance • What standard do we adopt/follow?
• Don’t reinvent the wheel (unless your cloud is not a cloud),
adopt the existing… • CSA STAR (Security, Trust and Assurance Registry)
Certification • Singapore Standard 584 Multi-Tier Cloud Security
(MTCS)
4
WHERE DO WE START
ISC2
Why the need for Guidance? • Provides the fundamental framework to build a
“SECURE CLOUD” • Systems security • Process security • People security
5
WHERE DO WE START
ISC2
Responsive Security • Trigger points • Detective controls • Correlation • BCM/ITDRP
6
INFORMATION SECURITY MANAGEMENT
ISC2
Paranoid Wise
Naive Apathetic
Knowledge Bar
Attit
ude
Bar
Don’t Know
Know
Don
’t Ca
re
Care
Responsive Control
Irrelevant Control
No control
No control – taking risk
SPOF (Single Point Of Failure) • Hypervisor security is a SPOF.
• Not proven but can imagine the potential impact • Hypervisor administrative/privileged access
• Managed as break-glass scenario. • Traditional security • 2FA?
7
POSSIBLE CONSIDERATIONS
ISC2
Vulnerability/Patch Management • When and how
• Not a straightforward exercise • Application dependency • Quarterly Maintenance Window (QMW)
• Governance support • Grouping of applications
• Based on RTO & RPO
8
POSSIBLE CONSIDERATIONS
ISC2
Standard Operating Environment (SOE) • Virtual machine (VM) sprawl.
• Any problem will be magnified in the virtual environment – more complex.
• SOE • Set the security controls/boundary • Set the configuration • Control-based approach
9
POSSIBLE CONSIDERATIONS
ISC2
Many players and layers • Complex security environment
• Physical layer (multiple sites, same controls?) • Network layer (SDN, NFV, etc)
• Enterprise security architect • Individual (risk of silos of expertise) • Group • Understanding the risk context consistently?
• Ideal will be to have an enterprise security architect who can piece altogether (technology partner).
10
POSSIBLE CONSIDERATIONS
ISC2
Double-edged sword • Virtualization layer
• Cloud can be used to attack others • Cloud itself can be attacked. • Going to be the next attackers’ front
• Management interfaces are often the weakest link – internal threat more likely.
• Proposed to implement 2FA to deter/control access from external and internal (Traditional security)
11
POSSIBLE CONSIDERATIONS
ISC2
Example: An attacker that compromises a web-based management interface can compromise all hosts on that server.
How real is this DDoS? • Internal DDoS Concern
• Virtual systems are also vulnerable to DDoS attacks – Serious and very real! • It will disrupt service by consuming resources.
• Traditional mitigating solution might not work here • Mitigating controls – Traditional security
• Hardening • Access control • Data control • Incident response
12
POSSIBLE CONSIDERATIONS
ISC2
Configuration Management Database • Dynamic environment.
• Do you have the updated inventory to start with? • Business requests to create, suspend and move VMs
around – how to control? • Change Management (Traditional security)
• SOE • Particularly useful in cloud computing
• Respective hardening guide (Traditional security)
13
POSSIBLE CONSIDERATIONS
ISC2
IT Audit concerns • New technology compliance
• Audited using traditional security controls? • Yes and No
• Back to school for auditors • Un-scanned, unpatched VMs to become active in
the network without any knowledge. • CMDB failure – Change management is critical • Security Acceptance Test (SAT) and Operation
Acceptance Test (OAT) are the respective gates to address any unauthorized change.
14
SECURITY & COMPLIANCE
ISC2
DevOps approach • Reality – multiple changes in 24 hours
• How to ensure proper SAT/OAT is in place before release?
• DevOps - is a software development method that emphasizes communication, collaboration, integration and automation. (SAT and OAT combined) • Cooperation between software developers,
Security and IT professionals is key • This is going to be difficult but achievable.
15
RELEASE MANAGEMENT
ISC2
16
OPERATIONAL FRAMEWORK - RESPONSIVE
ISC2
Time
Ope
ratio
nal R
eadi
ness
Incident
Maturity
Det
ectiv
e co
ntro
ls Audit
findings
Corrective controls
T + 0 T + 1 T + 2 T + n
Responsive security = Correlation + Early Warning + BCM/ITDRP
Adopt Responsive Security • Trigger points • Detective controls • Correlation
17
SOLUTION
ISC2
Paranoid Wise
Naive Apathetic
Knowledge Bar
Attit
ude
Bar
Don’t Know
Know
Don
’t Ca
re
Care
Responsive Control
Irrelevant Control
No control
No control – taking risk
Trusted advisor • Look out for a technology partner who invests in
R&D, understands the implications and relevancy of having a relevant technology.
• Understands IT and Information security.
18
SOLUTION - TECHNOLOGY PARTNERSHIP
ISC2
Hoo Chuan Wei CISSP, CISA, CFE, BCCE Technical Advisor, ISC2 APAC Executive Security Advisor, IBM Security
#CLOUDSEC
Hoo Chuan Wei CISSP, CISA, CFE, BCCE Technical Advisor, ISC2 APAC Executive Security Advisor, IBM Security
Recommended