By Eric Sheridan
“We programmatically interface with Cloud Providers to manage our customer data, so we can rely on them for securing our services right?” Wrong!
The moment you start interfacing with a Cloud Provider you immediately inherit the risks associated with their deployment, development, and security models – or lack thereof in many cases. However, you’re still responsible for the secure development of your business’s applications and services, but with the caveat that you are now sharing that responsibility with a Cloud Provider. Unfortunately, most Cloud Providers do not provide sufficient visibility into the maturity of security activities within their software development lifecycle.
Below we’ll take a brief walkthrough of a secure buy-cycle for a Cloud Provider and look at how you are affected by interfacing with Cloud Providers, and what you can do to ensure consistent adherence to secure programming patterns and practices.
Gaining Visibility into Security Activities
Gaining visibility into the security posture of a Cloud Provider requires a large amount of discussion and documentation review. There are several common security activities that I look for when evaluating a Cloud Provider. If I were to evaluate your security capabilities as a Cloud Provider, some of my very first questions would be:
Do you centralize application security initiatives?
As a user of your Cloud Provider services, I need assurance that your development team and management staff is enabled by a centralized security team to produce fully secured products. Show me that you have a centralized security team or standards committee. I want to see a team that is responsible for defining application security practices and standards as well as defines and recommends security activities within the organization. Don’t run your application security program like the Wild-Wild West!
Do you enforce an application security-training curriculum?
As a user of your Cloud Provider services, I need assurance that your development team and management staff is aware of the latest secure programming vulnerabilities and their mitigation strategies. Before you can begin addressing application security risks, your team needs to have an understanding of those core risks!
Do you facilitate secure development through automation?
As a user of your Cloud Provider services, I need assurance that your development team and management staff has the tooling necessary to streamline challenging security activities for quick remediation. This is simply a matter of scalability; humans alone are not a viable option for finding and fixing every problem in your codebase. Technologies such as Static Analysis Security Testing (SAST) and Dynamic Application Security Testing (DAST) help scale code review and penetration testing solutions by focusing on a common set of application security problems while additional human-resources apply more specialized techniques to the business contextual components of your services.
I do not want to hear that you “perform penetration tests on a yearly basis using a 3rd party firm and/or 3rd party tools.” This type of process is not continuous, does not enable developers, does not scale and leaves too many open problems.
Do you have incident response for dealing with security vulnerabilities?
As a user of your Cloud Provider services, I need assurance that you have a process in place to respond to vulnerabilities identified in production applications. I’m looking for a standardized process that is well understood by the key stakeholders in your business and the applicable business unit.
Show me the turn-around time for fixing vulnerabilities. Give me an understanding of compensating controls used to reduce exposure of exploitable vulnerabilities. Most importantly, show me who did what, when, and how. I cannot make educated and well-informed decisions for my business if you do not provide me with enough information from your end.
How do you ensure confidentiality and integrity of sensitive data?
As a user of your Cloud services, I need assurance that you have sufficient controls in place to protect my sensitive data throughout the service lifecycle. Tell me the protections you have in place when sensitive data is being entered into the application, when the sensitive data is transmitted across the wire, when the sensitive data is at rest, and when the data is presented to end users.
Key security controls that I am looking for in this regard include using FIPS 140-2 compliant cryptographic modules, masking of sensitive fields, use of Transport Layer Security (TLS) for network transmission, use of strong encryption and message digest algorithms for persistence, and a key management strategy that incorporates key rotation and processes to minimize disclosure. The last thing I’d want is you storing the cryptographic key in a database column adjacent to the encrypted data!
How can my team make use of your services securely?
As a user of your Cloud services, I need assurance that my development team will have all the support they need to systematically interface with your exposed API in a secure fashion. Show me clear and concise documentation of the security features and security characteristics of your exposed functionality. My development teams need to understand your authentication and identity management workflow along with guidance on how to manage those identity tokens.
My development teams also need to understand any security relevant assumptions you place on your exposed API. For example, are you expecting my development team to verify the user is authorized to access a database record by querying the UserEntitlments endpoint prior to querying the DatabaseRecord endpoint? Or have you encapsulated the authorization logic within the DatabaseRecord endpoint so that my development team only has to make one API call? I definitely don’t want to be responsible for disclosing my users’ information because you did not provide me guidance on how to securely interact with your service.
Verify Security Claims and Assertions
While simply hammering your potential Cloud Provider with application security questions like the aforementioned helps provide visibility into their security posture, it in no way verifies that they’re doing what they claim. In an ideal partnership, it is prudent for you to require your potential Cloud Provider to “get tested” by an application security team before moving the relationship forward. Whether an internal team or a 3rd party carries out the assessment, the goal of the effort would be to gain confidence that the Cloud Provider is properly adhering to and implementing their security claims and assertions.
The assessment should cover not only a code review and penetration test of the target services, but should also evaluate the capability of the Cloud Provider to implement their security activities throughout their Software Development Lifecycle. Use the vulnerabilities from the code review and penetration test to assist in the evaluation of their security activity effectiveness. Ask them:
- What vulnerabilities in this report are known and unknown?
- How long have you been working on remediating the known?
- Why do you believe the unknown were not previously identified?
- How long will it take to fix these vulnerabilities?
You can roughly estimate what security activity failed based on evidence from a combined code review and penetration test. If the vulnerabilities indicate a complete lack of security control(s), then there is likely a serious problem with the Cloud Provider’s planning and requirements phases. If the appropriate security controls exist but were not used correctly or there are various implementations of the same security control, then there is likely a problem in the design and implementation phases. If the vulnerability is substantial and was unknown, then there is likely a serious problem with the Cloud Provider’s secure coding enforcement strategies. Finally, if the vulnerability is substantial and known for an extended period of time, then there is likely a serious problem with the Cloud Provider’s incident response strategies.
Dig Deeper
There is a very common problem facing consumers of Cloud Providers today; they simply fail to dig deep enough in the selection process and settle for what looks good on the surface – a surefire way to build a short-lived relationship. You must realize that you inherit the risk of your Cloud Provider the moment you leverage their services. The risks are further compounded when sensitive information is passed through these Cloud Provider services. When you evaluate your future Cloud Providers, ensure that you gain visibility into their application security activities and you verify security assertions and claims through penetration tests and code reviews. After all, your Cloud Provider is a Partner…not a One-Night Stand!
Eric Sheridan, chief scientist, Static Analysis, is responsible for the research, design, implementation, and deployment of core static analysis technologies embedded within WhiteHat Sentinel Source. Sheridan brings more than 10 years of application security expertise to WhiteHat Security with a focus on secure programming patterns and practices. This experience has allowed him to infuse WhiteHat Security with the ability to create static analysis strategies and technologies that actually target the correct problem domain, thus enabling developers to produce more secure code. In addition to his static analysis expertise, Sheridan has enormous experience in defining, integrating, and executing security activities throughout the software development lifecycle.
Prior to joining WhiteHat Security, Sheridan co-founded Infrared Security; a company specializing in application security consultation and the development of next-generation static analysis technologies ultimately used within WhiteHat Sentinel Source. Aside from providing professional consultation services to organizations in both the Government and Private sectors, he frequently contributes to the Open Web Application Security Project (OWASP). Sheridan led the creation of the CSRFGuard and CSRF Prevention Cheat Sheet projects while contributing to WebGoat, CSRFTester, and Stinger.