CCSK Study: Domain 10 - Application Security

Notes

• Cloud environments challenge many fundamental assumptions about application security
• Can be a particular challenge for applications across the layers (SaaS,PaaS,IaaS)
• Application is solely responsible for providing security
• Cannot make any assumptions about external environment
• Application can be moved at any time
• Threat landscape is increased
• In addition to traditional attack vectors we must also consider attacks from within the cloud
• Example:  You could be running your application on the same infrastructure as your competitor
• Secure SDLC
• Differences vs traditional apps
• No control over physical security
• Incompatibilities vs different providers
• Think about DR plans and migrations
• Protection across the Data lifecycle
• Data at rest is still in the cloud, so additional protections may need to be considered
• The combinations of web services in the cloud could lead to security vulnerabilities
• Maybe in the business logic domain?
• Each service now has to authenticate and secure itself
• Ability to access logs is more difficult
• Need to consider Incident Response here or even just basic troubleshooting
• Fail-over for data and data security in the cloud has to be more detailed
• Compliance related tasks can be more difficult
• It it not necessarily enough that the Service Provider is compliant, the whole process needs to be
• Organizations should have an application security assurance program
• Basically, we need to ensure we are developing applications with appropriate considerations and controls
• Goals and metrics should be defined
• Security and Privacy policies should be defined
• Consider any relevant regulations
• Appropriate hooks within SDLC to ensure security is "built-in"
• training, etc
• Perform security and privacy risk assessments to ensure appropriate requirements are defined
• Ensure appropriate verification steps are defined 
• Configuration and Change management
• Requirements (security/privacy) have been met
• formal coding practices
• physical security
• Design Review
• Review design for the common secure-design principles
• See doc or "The Security Development Lifecycle" Chapter 8
• Also see Microsoft SDLC Design phase
• Code Review
• Pick guidelines to follow
• SAFECode, CERT, ISO Standards, OWASP
• Use both DAST and SAST
• http://blogs.gartner.com/neil_macdonald/2011/01/19/static-or-dynamic-application-security-testing-both/
•  Other considerations
• Remove comments / names etc from code (it is being uploaded to a 3rd party)
• verify all input, including computer and inter-system input
• Security Testing
• Cloud architecture may prevent this step (check with vendor)
• Conduct black box penetration testing
• Use a wide scope (include remote access systems, and other related IT assets)
• Interoperability Testing
• Need to ensure that data can be exchanged between various components or applications
• Test against reference implementations 
• ie: if you are using an open standard, test that the output is valid against that standard
• Test all pairs
• Test that the transfer is "secure"
• Quantitative Improvement
• We can only improve what we can measure
• Example metrics
• % of applications and data assets in the cloud evaluated for risk classification
• costs of the application security assurance program
• estimates of past loss due to security issues
• As much as possible, we should automate security controls / testing
• Application Security Architecture in the Cloud
• Considerations for cloud applications
• Lack of control
• Cloud subscriber does not control cloud provider security policy / enforcement
• Lack of visibility
• cloud subscriber cannot see cloud security policy enforcement and controls effectiveness
• Lack of manageability
• cloud subscriber cannot manage cloud provider app security (think audit and access policies)
• Loss of governance
• no direct control of infrastructure, cloud subscriber must "trust" cloud provider to do things right
• Compliance Risk
• cloud provider now becomes a "partner" in compliance and it's policy and process now become a part of the cloud subscribers overall regulatory landscape
• Isolation failure
• New threat to application.  Isolation failure could allow competitors to access/use protected data
• Data protection
• direct control over data is relinquished and the cloud subscriber now relies on the cloud provider
• Management interfaces and access configuration
• New threat vectors as management interfaces and now accessed over the Internet
• Technical Risks and Solutions
• Identify, Entitlement, And Access Management (IdEA) is a little more complex in cloud environments
• User management lifecycle is now extended into the cloud
• typical requirements
• Understand how on-boarding / off-boarding of users will be handled
• Special cases such as service-to-service integration or cloud-to-cloud integration
• Ability to use open standards (SAML, WS-FED)
• Risk-based decisions
• User, device, code, organization, agents, geo-location, etc
• Support for internal security / compliance requirements
• Audit of user activity (especially privileged users)
• Claims-based / role-based authentication
• Manageability of permissions
• Ideally, one permission store (on-prem) uses a "mechanism" to translate and sync entitlements to various cloud providers
• may want to consider open standards such as XACML
• Compliance Building Blocks
• Infrastructure Controls
• Ex:  protecting facility from natural disasters, electrical grid failures, etc
• Auditing considerations
• Access to data center
• system admin auditing
• internal security reviews
• Application Controls
• Special considerations for regulatory frameworks
• Multiple levels of security is required
• IdEA Management for Cloud Application Security
• Traditional edge network security devices have limited effectiveness in cloud solutions
• New perimeter could be defined as data and the method by which that data is accessed
• Definition of identity should be broadened
• Includes other information such as source device
• How the source device is managed / administered
• external B2B considerations
• Authentication
• The process of asserting the users identity to a given application
• Cloud considerations
• Plan to use open standards such as SAML vs traditional "authenticate to LDAP" type mechanisms
• Plan for BYOI (Identity) whereby 3rd parties and partners can use their authentication system rather than having to maintain separate username/passwords
• Consider alternative authentication methods to username/password
• Two factor such as RSA(nsa?) Tokens, OTP over SMS (has issues, more), Smartcard, Biometrics
• Plan for risk-based authentication
• Different security steps depending on device, user, location, heuristics
• Authorization
• the process of enforcing the rules by which access is granted to resources
• Plan to use open standards to communicate entitlements
• WS-policy for defining security and management policy assertions
• WS-security for enforcing access restrictions
• WS-trust for implementing STS
• Plan to use rule-based authorization model using claims and attributes
• Attribute security
• Ensure that attributes that are shared do not reveal the users identity (Privacy issues)
• Plan for attribute complexity
• There could be multiple attribute providers
• How to handle incomplete data
• Share only the minimum amount of information required
• Ensure that access policies and entitlements policies are manageable in addition to being technically enforceable
• Claims security
• Use meaningful claims
• Ex:  verified email vs email
• Consider the type, surety, freshness and quality of the claim
• Ensure authority on claim based on context
• ex:  some applications can make certain claims
• ex:  telco can verify user phone number, others can't
• Plan for a disparate cloud landscape where multiple different authentication mechanisms need to be in place
• how do you seamlessly authentication across all cloud applications
• provide for granular control
• Audit / Compliance
• 3 questions
• What cloud resources does a user have access to?
• What cloud resources does a user actually use?
• Which access policy rules were used as a basis for a decision
• Considerations
• Build IdEA in from the beginning
• consider claims as the access mechanism
• SAPM(Shared account password management) for managing highly privileged accounts
• Use open standards (SAML)
• Cloud apps should take into consideration various token types, OAuth, API Keys, etc
• Cloud apps could be dependent on others for services such as logging or db connectivity
• Ensure modular design during development
• Can switch out IdEA module in the future if need be
• consider STRIDE during threat modeling
• Spoofing controlled via strong authentication
• Tampering controlled via digital signatures
• Repudiation controlled via digital signatures and logging
• Information Disclosure controlled via SSL, encryption
• Denial of Service controlled via Security Gateways
• Elevation of privilege controlled via authorization
• Policy Management
• access policy management is the process of specifying and maintaining access policies to resources
• Consider attributes based on identity
• caller related
• context related
• target related
• Can also consider
• General state of IT landscape
• crisis level, or emergency situation
• other decisions
• prior approvals, etc
• attributes related to the protected target resource
• QoS, throttling
• 3 typical enforcement points
• Using a Policy Enforcement Point (PEP)
• external, internal, as-a-Service
• Embedded as part of the cloud app
• using Identity-as-a-Service or Persona-aaS
• Cloud Issues
• Cloud subscriber at the mercy of enforcement points / decision making points already built into the application
• Ie: subscriber may not be able to define their own set
• Controlling access to multiple nodes / interconnected clouds
• Need to decide between identity/entitlement centric vs protected-resource centric
• Generally the PEP is the protected resource, so we need to find a way to package the information up and send it to that resource
• Identity is just one consideration
• Policies need to be in a manageable form
• Expressed in business terms and at a high enough level of abstraction that it can filter down and tools can be used to express the policy for each resource as required
• There could be many access policy providers
• How to integrate and manage them?
• Format (eg: XACML)
• Updating of PDP/PEP in a timely manner with correct(fresh) data is important
• Managing Access Policies For Cloud
• in-short, this is hard
• No real mapping exists between technical control points and business language
• Tools are required to convert Business DSL to technical controls
• Best practices
• Decide between identity-centric and resource-centric security models
• Ensure manageability of resources
• Designate clear responsibilities for policy management vs policy auditing
• Aim to have subscriber specific authorization policies
• Consider use of Policy as a service
• Consider generation/update of policy
• Aim for automatic generation tools/capabilities
• Use open standards
• Consider the use of PEP/PDPs with hooks for policy monitoring points / audits / compliance
• Application Penetration Testing for the Cloud
• Where applicable, do pen testing
• SaaS providers may not allow for this whereas PaaS and Iaas may have some support
• Use a framework
• OWASP ASVS
• OWASP Testing Guide V3
• Consider additional threats
• Isolation failure
• VM escapes
• Application Security Monitoring in the cloud
• Things to consider
• Log monitoring
• Performance Monitoring
• Monitoring for malicious use
• Monitoring for compromise
• monitoring for policy violations
• Requirements need to be defined and work needs to be done to see how the cloud provider can provide access/views to the information required
• Logs should be
• Easily parsable
• Easily readable
• Well documented
• Monitoring "ability" varies between cloud provider type
• IaaS == almost normal
• SaaS == OMG!
• Need to establish what access a cloud subscriber will have and how the cloud provider will notify/transmit information to the subscriber

Summary

This was quite a long and involved chapter.  It covered a few key points.  Once again, most of this should have factored into consideration for traditional app deployment, cloud simply adds on some complexities not yet though of.

An SDLC is key.  Building security in to the process it the best way to go.  I think that two most important tasks in any SDLC is to ensure that the team has adequate training on the threats and mitigation techniques and that there is enough work put into defining security requirements as per policy and best practices.  Additional things to consider would be things such as DR, data recovery, incident response / monitoring.

Authentication and authorization is interesting in the cloud scenario.  Ideally, you do not pass passwords to any cloud provider.  In this case, federation is key.  An extension of this is to not pass the identities either (in the traditional email / userid sense).  This is where attribute or claims based authorization comes into play.  One special case is when you start to daisy chain cloud services together.  In a traditional architecture, it is easy to take a back end service (db, web) and block any access to that except from the front end application.  As everything lives in the cloud, this becomes harder to do.  I think the discussion between identity centric and protected resource centric authorization is an interesting one, and one that I need to research further.

When I hear about application penetration testing in the cloud, I think "forget about it!".  I think the best point here is to do a paper pen test whereby you review source code, as-is documentation against the threat vectors.  I did a pen-test on a service now implementation only to find out that all controls were built client side in javascript as opposed to server side.  Discovery of this would have been easier had I just had a chance to review the code and talk to the lead developers.

As with pen-testing, monitoring is another one that where you are really up to the mercy of the cloud provider.  Security monitoring requires real tangible things such as ram/cpu/disk.  Security enforcement, even more so.  Cloud providers are in the business of delivering those resources and as such, want to charge for everything.  I think when designing a solution, we need to understand what hooks we will be provided, and how much it is going to cost to implement controls.  Sure, in an IaaS environment you could run AV, firewall, etc at the OS level.  But think of the cost of that.  It would be much better to run a majority of those services at the VM layer, but you may not have access to do that.