Security Requirements & Cloud Computing
Matthias Luft ERNW GmbH [email protected]
ERNW GmbH
- Independent
- We understand corporate - Deep technical knowledge
- Structured (assessment) approach
- Business reasonable recommendations
- Blog: www.insinuator.net
- Conference: www.troopers.de Heidelberg based security
consulting and assessment company.
Agenda
¬ Basic Cloud Terms
¬ ERNW CloudSec Approach
Definition
Definition
Definition
Definition
Service Layers
Data Center Server Hardware Infra-structure Virtualization/Abstraction StorageAPI Integration/Middleware Data Store Software Configuration/Management Interface G ov er na nc e/ M on ito rin g/ B ill in g M an ag em en t A P Is /M an ag em en t W eb in te rf ac es Ia aS P aa S S aa S
Deployment Models ¬ Public
- Sold cloud services
¬ Private
- Operated for (not necessary by) a single
company
¬ Community
- E.g. industry wide cooperation
¬ Hybrid
There Is No Cloud
¬ There are many clouds.
¬ There is no cloud technology. ¬ There is a composition of
- Hardware
- Technologies
Introducing the
System Operation Lifecycle
1. Hardware is purchased. . .2. . . . from trusted hardware suppliers.
3. The hardware is operated in own data centers. . .
4. . . . which reside in carefully selected countries and locations. . .
5. . . . and are secured by carefully selected access control mechanisms.
6. The hardware is operated by trusted employees. . .
7. . . . who install operating systems. . .
8. . . . from trusted install media. . .
9. . . . in a secure, documented way.
10. The operating system is secured by carefully selected controls.
11. Only approved applications are installed. . .
12. . . . from trusted install media. . .
Approach
① Analyze asset for security
requirements
② Define cloud use case
③ Map use case to system operation
lifecycle
④ Analyze security requirement
gaps
⑤ Perform additional risk/trust assessments
Asset Analysis
¬ Define security requirements and
objectives.
- Existing documentation might help ;-)
¬ No formal approach necessary:
- Risk analysis, development
Cloud Use Case
¬ Service model:
- IaaS, PaaS, SaaS?
¬ Deployment model:
- Public vs. private?
¬ Cloud Service Provider?
Ø Map outcome to the system operation
Map requirements and find gaps!
1. Hardware is purchased. . .
2. . . . from trusted hardware suppliers.
3. The hardware is operated in own data centers. . .
4. . . . which reside in carefully selected countries and locations. . .
5. . . . and are secured by carefully selected access control mechanisms.
6. The hardware is operated by trusted employees. . .
7. . . . who install operating systems. . .
8. . . . from trusted install media. . .
9. . . . in a secure, documented way.
10. The operating system is secured by carefully selected controls.
11. Only approved applications are installed. . .
12. . . . from trusted install media. . .
Additional Assessments
¬ Risk assessment/acceptance ¬ Trust assessment
¬ Additional technical/organizational/
Cloud Pentest
¬ Evaluation of a SaaS CSP
- Some “HR management software”
¬ They agreed to perform a pentest
on behalf of the potential customer.
Cloud Pentest
¬ Lifecycle: Software in SaaS cannot
be controlled.
¬ Requirements: Compliance of the
software with corporate security guidelines.
Pentesting SaaS
¬ Target of evaluation: HR web
application
① Typical web application pentest
Pentesting SaaS
¬ Basic result: After one day, we stopped
the test.
- We already had more severe findings than
in some other 20 man day tests ;-)
- File upload to the web root was possible
(= code execution in a multi-tenancy environment…)
¬ So, no need to test cloud related
Auditing Major CSPs ¬ Since many customers are interested in
Amazon as a CSP, we perform a lot of tasks in the Amazon cloud.
¬ In the course of one of our regular password audits, we discovered some abnormalities in the Amazon login procedure.
- Drop that, we wanted to break that stuff ;-)
¬ Bruteforce attempt against the Amazon Web Services login form
- Using our own account
Right to Audit
¬ Requirement: All accounts have to
comply with corporate security guidelines
¬ Amazon account management not
under control
Setup
¬ Tricky since bruteforcing tools do
not cope well with modern webapp authentication mechanisms
- Cookies with different scopes, redirects,
JavaScript
Results
¬ Burp might not be the best choice for bruteforcing.
¬ Still, good performance
- ~80k requests per hour
¬ Setup was implemented in ~20 minutes
- More details can be found here:
- http://www.insinuator.net/2011/07/the-key-to-your-datacenter/
Conclusion
¬
Bruteforcing is possible. Big
surprise?
¬
More important:
- No connection throttling! - No account lockout!
Amazon Aftermath
¬ Very good response of the Amazon
Security Team!
¬ Fast implementation of a captcha
solution.
¬ Re-evaluation of our bruteforce
Mapping Real World Requirements…
¬ Analysis whether an n-tier application
hosting environment can be migrated to the Amazon Cloud.
- Business unit wanted to use Amazon due to
“flexibility and cost savings” ;-)
N-Tier
Sample Requirements Analysis
¬ First step: Evaluation of security requirements
¬ Second step: Mapping of those requirements to
potential controls, design decisions, and services in the Amazon Web Services cloud.
¬ Main goals of the project:
- Which cloud deployment models can be used? - Which advantages/disadvantages result from these
deployment models compared to the operation in own data centers?
- Which are the adoption pitfalls?
- Which regulatory requirements come into play when using a AWS setup and how to comply with those?
Derived Requirements
¬ Network Zoning & Filtering
- Different network zones for each tier, filtering
between tiers must be possible.
¬ Processing of customer data (personal data)
¬ Same availability as in own data center
¬ Latency between the different network zones - Need to be lower than 5ms (due to application
Network Zoning
¬ Three possibilities:
① Amazon VPC Subnets: Pure ACLs
② Different VPCs connected to corporate
filtering mechanisms by IPSec
Customer Data
¬ Processing of customer data
- German data protection laws
- According to [OH_CC] not possible for
personal data without special contractual requirements
- => Data-tier must potentially be hosted
Latency
¬ Latency
- Much higher in cloud environments,
cannot be guaranteed
Availability
¬ No actual SLAs guaranteed ¬ Uptime statements
¬ No reimbursement
¬ For IaaS, high availability still has
Additional Problems
¬ Extensive adjustment of operational processes
necessary.
¬ Patch & vulnerability management needs to be adjusted. ¬ Provisioning processes: Custom AMIs necessary
- E.g. data-tier requires IBM DB2
¬ Nice-to-have: IDS between network zones ¬ External business partner connections
¬ Monitoring & logging must be adjusted for the cloud
environment
Ø Advantages might materialize, but extensive
restructuring and adoption necessary. Not feasible for only one application.
Conclusions
¬ Know your assets
- Should not be surprising ;-)
¬ There is no cloud…
¬ … but a lot of technologies!