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