Just as in any childhood game, the first thing that happens is knowing or being taught the rules of the game, or agreeing to the rules that will be used in the game. Cloud security is no different, but many times, we get bogged down in the details and agreeing to the high-level “rules.”
So why can’t we place the rules in the cloud to keep them safe, or at least make them someone else’s problem? The answer is a big “NO!” Cloud comes in all flavors (IaaS, PaaS, and SaaS) and uses the SHARED responsibility model.
Many times when you look at an organization’s cloud deployments you find, a large number of instances that do not have a valid or single owner, backups and restores that are not monitored, groups not adequately used for users, default settings overridden by administrators, auto-suggested controls not implemented, no gateway or firewall monitoring for public-facing servers, “Pay as you go” subscriptions, and alerts disabled or not configured, giving everyone administrator access, or having a lack of “security” groups, and API deployed using the unencrypted connection (HTTP). Anyone of these can cause issues, and most likely is a problem. These are the easy and simple things, the technical controls, and we are not going into the difficult things like lack of network design, lack of documentation, lack of an instance catalog, and use of trail instances for productions.
Moving things to the cloud is no different than before and does not change some of the things that you still need to do as part of any information technology deployments. Responsibilities shift but do not change. The overall complexity can be managed; left alone, it soon becomes out of control.
You have the three things you can control: people, processes, and technology.
So here are some of the significant rules for moving things up to the cloud.
1.) To make sure you are ready to move to the cloud, you need a few things first.
a. Know the reason, know the data sensitivity, and know success and failure
b. Be sure to list all third parties performing work on the program
c. Be sure to identify all Software As a Service (SaaS) providers
d. Be sure to identify all systems that are being integrated with both on-premise resources and cloud resources
e. Be sure to locate all Infrastructure As a Service (IaaS) providers
You need this information, as it is like the blueprint to build the house. It will be a small disaster if you do not have it; it will collapse on itself or implode. As always, it is much harder to make changes in the future.
2.) Be sure all third parties that are performing work on the project or program have passed a security assessment. Be sure the contract contains a security addendum. Advise partners that only minimal changes to the addendum will be accepted.
When adding some level of expectations around third parties or partners, as cloud security is a shared responsibility model, you need to inform the third parties about what your expectations are and penalties around data handling, bugfixes, and background checks. Organizations should address but not necessarily pay for vulnerabilities found in the code or libraries.
3.) Be sure all SaaS providers have passed a security assessment. Be sure the contract contains the security addendum. Advise partners that only minimal changes to the addendum will be accepted. If the SAS’s legal template is to be utilized, then it must have additional legal, privacy, and security reviews. The SAS’s legal template is designed to protect the SaaS’s interests, not your company’s.
Software as a service is just that, and the contracts are around protecting that software and not your application, data, and responsibility. Make sure you address this as best as you can, knowing that you will hear “No one has ever asked for this before.” Do not let that discourage you, but you need to know what responsibility you have and make the business and application owners know, as well, as it might require additional expenditures. With nothing in the contract, you might be forced to use it, even after a breach.
"Going to the cloud, using the cloud, and operating a cloud is all about the basics, keeping up with the “Big Rules,” and making a smooth transition and more comfortable operation"
4.) Third parties must use organization-managed computers to perform work for the company regardless of where the work is being done. Exceptions for large, heavily protected companies may be granted after an additional detailed security review. All work must still be performed with an organization account.
As security is a holistic science or art, the need to be able to look at all aspects of the resource supply chain, including traceability, location, and what tasks were performed, is essential. It becomes critical not only when something goes wrong but as something is being built, as well.
5.) All cloud-service platforms must be owned by a company service account that is owned by a team responsible for ALL cloud accounts. This way, if someone leaves the company, the organization can still control the instance or application.
Sometimes, the little things are the things that slip. From email addresses to accounts to ownership, making sure that the business owns and always controls the environment is critical. Often, this is overlooked due to the ease of setup and trial usage that moves straight to production. When other companies or employees have control over the instance, the question becomes what happens if they leave or become disgruntled. The billing information is sent to a personal email address, or it is paid with a corporate charge card. These can be easily prevented but may be hard to discover or change in an existing environment.
6.) All cloud services platform instances must be appropriately in tracking documentation and be shared within the company, with teams like security, network operation, and helpdesk. A list of administrators and users with access to this instance must be maintained and shared with the security and operation teams and kept up-to-date. A detailed cloud instance diagram should be created, not the simple block diagram with names like “cloud” but with names of systems (virtual and logical), ports, and services used, as well as the flow of information.
The need to keep proper documentation is critical for the success of cloud instances. Partners, employees, and others will come and go, keeping track is vital, and knowing who had/has/needs access is crucial from a security and operational perspective.
7.) All production and non-production cloud service platform instances must be protected by IP whitelisting, (You should be blocking everything and only allow this list) to ensure that only authorized IP address ranges can gain access to the instances from internal or external resources.
In the cloud, everything is in production, so leaving apreProd/Test/UTA/QA is open to the internet is just irresponsible and lazy, as having networking that works correctly from the start means you can fix something correctly instead of using a band-aid approach. Blocking IP addresses is security 101, but in the cloud, understanding what is sending data, how it is communicating data, and the need to send data is already complicated. Add an application, and soon, it is overwhelming. This is fixed by allowing all traffic to flow around the cloud as needed. The issue then is that it becomes hard to find and troubleshoot issues, raising a huge security problem. If traffic is blocked from the start and documented, it is easy to know when things work and when they do not.
8.) All cloud service platform administrative consoles must be properly protected using a form of MFA (multi-factor authentication) to ensure that only authorized accounts have access. Administrative access must be approved by security and regularly audited by operations to ensure a limited number of individuals have access. Also, allowing for read-only accounts for audit purposes is critical. Have the instanced administrative, audit, and performance logs sent to the security logging environment.
There is no reason not to secure the cloud platform consoles as they are the crown jewels of an organization. Controls like MFA, which allows additional controls, can be added. Another option is VPN-only access, where a user must be on the corporate network to access the cloud platform. This is a good practice, but it can often be problematic for third parties. Having data logged to a centralized area allows you to monitor and be alerted on issues from performance to security.
9.) All application access tokens or application authorizations must be added to a tracking sheet and shared with the security team. Processes must be in place to manage and protect the tokens/permissions. Exposed or unprotected tokens require a mandatory reset.
Designing an easy process for account approvals is critical to success, as people will need access for short periods, and knowing what accounts are active and for what kind of services is critical. If you start with a clean and managed cloud instance, you will always have one; it takes ten times the work to clean a cloud instance up.
10.) All code, software artifacts, configuration files, and build files must be stored in approved and protected source code repositories under company management. All builds must be labeled under the version control system. No third-party machines can be used as part of a build process.
Keeping track of cloud instances can be a considerable task. Being organized is the key. Force some simple rules to keep everything in place and allow for maximum flexibility and security.
11.) All production changes must be through approved build procedures from production source code repositories and follow documented release procedures. Development end-user machines should not be used for production releases. Third-party machines must not be used for production releases.
Being in a cloud instance does not change good IT practices or management. Making sure of who or what is building your instances is critical. Keeping that focus will help you when something goes wrong and will allow you to focus on the correct area vs. the entire cloud instance.
12.) Security scans must be integrated into the build process for software and cloud infrastructure.
Nothing causes more friction than security issues. In a “go live” environment, fixing these early keeps the development cycle on track and keeps the cloud instances secure.
Going to the cloud, using the cloud, and operating a cloud is all about the basics, keeping up with the “Big Rules,” and making a smooth transition and easier operation.
Check out: Top Web Security Solution Companies