Security cannot be extricated from an understanding of the threat landscape, and cloud environments are no exception.
To that end, a key part of security is threat modeling, which can be used not only to improve cloud security, but also as the starting point of offering security assurance to customers.
“Security decisions are made based upon risk – risk of exposure, risk of breach, risk of loss, risk of availability, etc,” explained David Baker, chief security officer at identity management vendor Okta, who along with Robert Zigweid of ioActive at the Cloud Security Alliance’s [CSA] recent CSA Congress Event.
“Threat modeling,” he told SecurityWeek in an email interview, “is a key method of attaching a real-risk value…at a granular level to technical components of a complex system. Development teams that have successfully implemented a secure development lifecycle leverage threat modeling to identify security flaws in their software even prior to code being written. Thus it can not only help guide risk-based security decisions, but it is used to implement mitigation strategies to the identified threats.”
This is just as true in cloud environments as it is elsewhere.
“Data availability and accessibility to the cloud service provider [CSP] are big concerns,” he said. “For example, how many people or who from the CSP have access to the data that is put into the cloud service. From there, it evolves into how that data might be stored and used. Is the data encrypted at rest? Is there a strong key-management system behind that encryption, or is it just a file-system or database driven encryption?”
Threat modeling, he explained, assigns mitigation or acceptance criteria to these vulnerabilities so that the threat can be evaluated on a risk basis. As an example, he proposed a situation where the concern is the threat that a user’s credentials could be compromised through a service’s Web UI [user interface]. The threat exists due to the Web UI being vulnerable to cross-site scripting and other vulnerabilities, and to accept or mitigate this threat, customers will often demand evidence from the provider that penetration test has been performed on the Web UI to find and fix all injection-based attacks.
Whether or not the vulnerability actually existed, the model has assigned it to the component – in this case the Web UI – and laid out evidence of penetration testing and fixes, said Baker.
According to Zigweid, director of services at ioActive, many threats to cloud computing are outside the control of the customer, and it is up to the cloud provider to provide assurances that these threats are mitigated.
“That being said, there is more to it than just seeing which CSP can provide an external penetration report – that is certainly missing the point of performing the threat models,” he said in an email. “As a customer, you need to understand not only the specifics of how you will be using the cloud service, but also dig into the details of the cloud service that lay outside of your trust boundary, i.e. your security perimeter. What APIs are being used and how? What additional upstream providers are the CSPs using? How is the CSP’s automation tested and validated?”
“To that end, the CSP should be able to not only provide assurances of these components in the form of third-party pen tests and compliance certifications, but should be able to provide test instances for your team to validate and test themselves,” he added. “This last part is the best way to evaluate the security – and transparency – between vendors.”
