Recently, I met with a government customer who made the following comment regarding his agency’s initiative to move to cloud-based resources:
“I know I can handle the technical part of the migration, but it’s the red tape that I’m the most worried about.”
The customer was referring to the mandatory compliance and governance policies all agencies are required to fulfill. This is not an uncommon remark I hear when talking to various customers about cloud computing implementations. I want to take this opportunity to highlight a few key policies that you should be aware of when considering moving to the cloud and outline a simple strategy to ensure that your organization will be compliant.
Below is a sample of some of the policies and standards often required for government agencies:
- Federal information security management act (FISMA) - A wide range of specific controls pertaining to IT management required for all government agencies to develop, document and implement a system based on the national institute of standards and technology’s (NIST) special publication 800-53. This includes considerations like, securing a physical or virtual infrastructure by establishing certain operational processes as well as a 3rd party audit of these processes.
- SAS 70/SSAE 16 - The statement on auditing standards no. 70 (SAS 70) is an accounting standard nearing the end of its use and being replaced by the statement on standards for attestation engagements no. 16 (SSAE 16), which is a global framework used for reporting on controls for service organizations and used throughout the U.S. government. These standards are auditing standards published by the American institute of certified public accountants (AICPA), and examine the operational effectiveness of certain IT controls such as an annual financial audit.
- Sarbanes-Oxley section 404 (SOX 404) – The public company accounting reform and investor protection act/corporate and auditing accountability and responsibility act (public law 107-204), more commonly known as Sarbanes-Oxley or SOX, was enacted in 2002 to enhance standards for all U.S. public company boards. SOX Section 404 requires company management and an external auditor to report on the adequacy of internal financial reporting, resulting in annual financial statement reports filed with the U.S. security and exchange commission (SEC).
- ISO 27001 certification – An information security management system (ISMS) standard published by the highly-regarded International Organization for Standards (ISO), which ensures a set level of security is inherent in the technological solution and maintained over the lifecycle of the solution.
- Payment card industry data security standard (PCI DSS) – A standard from the PCI security standards council, which maintains the integrity of any organization that handles credit card information.
- Federal information processing standard publication 140-2 (FIPS 140-2) – Is a U.S. government security standard for cryptographic requirements.
- Federal risk and authorization program (FedRAMP) - Maintained by the U.S. general services administration (GSA),this program provides a government wide, standardized approach to security assessment, authorization and continuous monitoring for cloud-based products and services. A certified third party organization audits and certifies cloud providers based on a set of mandates and controls established by the office of the U.S. CIO. The cloud providers will be certified once and then able to be used many times by different government organizations.
- The health insurance portability and accountability act of 1996 (HIPAA) – A set of national standards for the protection of an individual’s health information. This legislation regulates the use and disclosure of this protected health information in order to protect an individual’s privacy rights. At the same time the regulation allows for the flow of information for proper use to allow for greater accessibility and information
Next, I’d like to outline a general four-part approach to help ensure compliance.
- Information phase: This is when you begin collecting all information about the current IT environment, along with the pertaining standards for your organization (this is a vital step). After analysis, you compile a list of compliance requirements and compare this against the documentation of the providers’ you are choosing between. This is an interactive and iterative phase, so be sure to engage all of your resources including providers.
- Design phase: At this point you are ready to start the design and implementation of the controls specified by your specific compliance requirements. It may be useful to consult with subject matter experts (inside and outside of the government) if you do not have the resources available within your organization.
- Roles and responsibilities phase: Based upon your risk tolerance, it will be important to know which controls are within your organization and which will be given to outside parties such as your provider, or any partners they may bring on board, to perform any additional services. In this phase, it is important to understand who is going to control what so that the risk can be fully understood.
- Verification/Audit: You must verify all of your compliance requirements are met in the final design and are operating effectively. There are many tools available on the market to ensure that these controls are operating effectively per the architecture. It may be beneficial to consult with someone who knows how to use these tools to help you verify that your design is compliant.
It is important to mention that the above is a general guideline. In order to be fully compliant, you need to tailor your approach based on your organization’s overall goals and consult with the appropriate experts to ensure that you are not missing anything. There may be specific controls and standards which your organization may be held accountable that have not listed here.
The strategy put forth here will help you to attain your goal of creating a fully compliant cloud-based environment.