Is it important to account for or acknowledge risks that may not apply to an organization or system? What if you identified a risk that you would typically consider for but would not use due because of the context. Say, for example, your organization is not in a floodplain however it is usual to consider for the flood risk for all locations of your organization. What if you have validated with FEMA 100 Year Flood Zones that the total risk facing the organization is very low since it is not in a location that requires flood insurance? Do you still need to acknowledge the possibility of the threat occurring?
I believe it is essential to acknowledge the risk. We need to document it as very low risk, and very minimum safeguards are required as part of risk assessment. The building code of the location would define minimum safeguard. However, there could be situations where the asset value of the site is very high that you cannot ignore the risk altogether. Say the location is the primary data center for the organization. In such situations, the organization must implement all appropriate controls required to protect from the flood. The assessment needs to be revisited periodically to determine if the risk is significant or not at that time. Each evaluation must be based on current facts and numbers at the time. Continue reading “Acknowledging Non-Applicable Threats”
The past year was a learning curve on Cloud Computing, especially on SaaS providers. More and more ASPs are coming back rebranded as SaaS provider. As a security practitioner, it would be good to have a must have check list that we need to use to assess them.
I prepared the following must have check list based on Cloud Computing Alliance Guide (v1.0) document. “SaaS Provider” mentioned is the vendor providing the cloud computing service and “Consumer” is the client or end user of the “SaaS Provider”.
Governance and Enterprise Risk Management
- SaaS Provider must provide at least SAS 70 Type II or equivalent certifications (e.g. Agreed Upon Procedures) SAS70 Type 2 is a mandatory requirement if the service is a SOX critical or within financial statement audit scope. If Credit card information is involved, PCI DSS compliant certification is required.
- SaaS Provider must provide Consumer listings of all third party relationships that it have; and similar audit assurance requirements as above are applicable. The vendor is expected to obtain such audit assurance from 3rd party subcontractors and provide to service consumer upon request.
- SaaS Provider must divulge policies, procedures and processes comprising its Information Security Management System (ISMS)
- Consumer must have authority to define Service Level Agreements with SaaS Provider
- SaaS Provider must incur all costs for both an expected and unexpected termination of the relationship and for an orderly return or secure disposal of Consumer assets.
- All of Consumer’s data must be destroyed from the SaaS Provider systems and environments upon the termination of the contract/services and upon completion of the transition and conversion to Consumer’s chosen platform and receipt of confirmation of the same from Consumer’s executive sponsor and/or legal counsel.
- Consumer information assets must not be used for secondary purpose including use of Consumer asset as test data.
- SaaS Provider must host all Consumer information assets in a country that Consumer is confortable with (based on regulations that Consumer is subjected to).
- SaaS Provider must accept all costs related to data breaches if possible including recovery costs
- SaaS Provider must not share Consumer information assets with a third party or government entity without prior consent.
- Consumer must have escrow arrangement of SaaS Provider software and applications
- Consumer must have authority to define roles and responsibilities related to Electronic Discovery, including such activities as litigation hold, discovery searches, who provides expert testimony.
- Compliance and Audit
- Consumer must have authority to define type of control that will be applied to locations where data will be stored.
- Consumer must have authority to audit SaaS Provider on demand
- Consumer must have authority to perform external risk assessments, including a Privacy Impact Assessment on the SaaS Provider
Information Lifecycle Management
- SaaS Provider must retain and destroy Consumer information asset per Consumer security policies and standards.
- Consumer must have authority to perform regular backup and recovery tests to assure that logical segregation and controls are effective
- All regular backup must be received at a data warehouse owned by Consumer.
- SaaS Provider must have logical segregation of duties of personnel.
Portability and Interoperability
- Consumer must receive regular data extractions and backups to a format that is not proprietary and is reusable by Consumer
- Traditional Security, Business Continuity and Disaster Recovery
- Consumer must have authority to define business continuity and disaster recovery requirements
- Consumer must have authority to perform onsite inspections of SaaS Provider’s facilities whenever required
- Consumer must have authority to inspect SaaS Provider disaster recovery and business continuity plans
Continue reading “Security Must Haves in a SaaS Provider”