Posts Tagged ‘Information Security’
The technique that uses both contextual and historical user information along with data supplied during an internet transaction to assess the probability of whether a user interaction is authentic or not is called risk based authentication.
Traditional username and password along with information such as who the user is, from where the user is logging in (IP address and information of the location from where the user is actually in at the time of transaction), velocity of the transaction (the process of verifying if its possible for a person who recently logged in from location 1 could login from location 2) and the type of device the user is using are considered as contextual information.
An online search shows majority of tools available for wiping out data on a disk points to a practice of 7 wipes. They believe that it is a US DoD requirement. Some of them support the Gutmann method of 35 wipes.
However, I could not find any documentation on US government website that indicates seven wipes. The US DoD 5220.22-M, “National Industrial Security Program Operating Manual that most online tools refers to does not have any requirements of number of wipe passes. However, I found a wiki page on Data Remanence that has enough citation and it contains the following -
“As of November 2007, the United States Department of Defense considers overwriting acceptable for clearing magnetic media within the same security area/zone, but not as a sanitization method. Only degaussing or physical destruction is acceptable for the latter.[4]
On the other hand, according to the 2006 NIST Special Publication 800-88 (p. 7): “Studies have shown that most of today’s media can be effectively cleared by one overwrite” and “for ATA disk drives manufactured after 2001 (over 15 GB) the terms clearing and purging have converged.”[1] An analysis by Wright et al. of recovery techniques, including magnetic force microscopy, also concludes that a single wipe is all that is required for modern drives. They point out that the long time required for multiple wipes “has created a situation where many organisations ignore the issue all together – resulting in data leaks and loss. “[5] ” Read the rest of this entry »
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 MFC upon request.
- SaaS Provider must divulge policies, procedures and processes comprising its Information Security Management System (ISMS)
Legal
- 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
Electronic Discovery
- 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