Three Criteria for Evaluating Public Cloud Storage Providers

Prior to selecting a public cloud service provider, it is essential that you understand what each vendor offers and how their services can best meet your organization’s needs. A move to the public cloud is a major shift in an organization’s architecture, and it provides many computing and performance benefits that are not available from a locally installed storage network. But before selecting a public cloud storage provider, you must ensure its offerings are a good fit for your organization. Some factors to consider:

Cost.  In many cases, monthly billing may be the least expensive option. However, understanding how much public cloud storage your company needs upfront will make cost guidance with vendors easier.  Especially, knowing the types of applications that will be hosted in the cloud will also affect the total cost. Knowing how these applications work will enable you to determine if storage will go up slightly based on transactions and the amount of bandwidth (upload/download) used.

Architecture services. Providers offer different storage replication options. For example, some services replicate your data to multiple data centers that are geographically distributed. You should review these in detail to determine how each one could potentially affect your architecture and compliance, especially for storage of sensitive financial and personal data. Another consideration is how public cloud storage providers will back up data or have storage moved from less redundant disks to more redundant storage . Be sure to ask what type of hardware the provider uses, as well as the speed and IOPS of the storage.  Lastly, each cloud storage service provider offers certain unique services. Examples include cloud storage gateways, API management and long-term data storage. Review these to see which ones could help you manage your storage more efficiently.

Sovereignty and security. There are two major considerations when dealing with public cloud storage providers. Questions to ask include the following:

  • How does the provider handle ownership of your data?
  • How is data segmented in a public tenant space?
  • How is the data encrypted, and who has access to it?
  • In which region will your data be stored?
  • How is the data terminated if your organization decides to leave the public cloud service provider?

Failure to ask these questions could leave your organization feeling trapped by a provider.

When vetting public cloud storage providers, the security of its systems should be reviewed to see where it matches and, in many cases, possibly exceeds the security of your company’s internal storage network. Organizations in industries such as finance and healthcare must meet compliance standards for data that’s stored in the cloud. A cloud provider should have the appropriate documentation for meeting these standards. When making the move to public cloud storage, remember to include the security team and auditors in the decision-making process especially to help determine which compliance considerations are most important for your industry.


Are You Ready for Your Pen Test?

It is day three of a five-day penetration test engagement and we still don’t have all the information we need to proceed with the test. This particular test was scoped to focus on internal applications and we were to gain access to those applications through the client’s VPN solution. But instead we find ourselves waiting on the process to get VPN credentials. This probably means we have some late nights ahead so we can catch up.

This and many similar scenarios are unfortunately all too familiar to third-party penetration testing teams. Below are a few things companies should consider when engaging a third party for penetration testing or other security testing. All of these tips assume gray-box testing, where the security testers are provided with some information in order to expedite the test and make better use of time and money:

User Accounts. For applications, the rule of thumb is a minimum of two accounts per major role. In the simplest of applications this usually means two user accounts and two administrative accounts. In more complex applications six or eight or even ten accounts may be needed. Without these tests for vertical and horizontal escalation of privileges cannot be implemented.

Code Stability. Ensure that by the time your security testers are looking at it, the code is more than half-baked. Much of the security testing you do too early will become invalid if your developers are still in the middle of building out features. If the code can’t pass your QA team, then it isn’t ready for third-party security testing.

Whitelist. Beware of what is your primary goal of the test. It is often a waste of your time and money to spend half the penetration test circumventing a WAF or firewall rules. If the emphasis is to specifically focus on the host or application security on your network, then it will be much more efficient to whitelist these controls. Additional tests, towards the end of the testing window can be performed with the WAF in place.

Testing Assets. For mobile applications, security testers may need access to the binaries, so if the test is on a pre-production build they will need access accordingly. If you have implemented certificate pinning in your mobile application, it is most efficient to provide security testers with a version of the app minus the certificate pinning. For web services, most likely your goal is to determine if your developers are implementing their code in a secure fashion. This can be done by running sample HTTP requests for valid web service calls, or valid requests saved in tool projects (such as SoapUI or Postman).

Other Administrative Headaches. A number of additional things can go wrong when preparing for security testing. Perhaps you need your third party to connect in through a VPN. Perhaps you have to open a change window to start the test. Perhaps your dev team runs an automatic deployment in the environment being tested at 10am every day, taking the server offline for an hour and creating a moving target for the testing team.

It is ultimately in the client’s best interest to start on schedule. If a client’s delay at the beginning of the week results in testers having to work extra hours late into the night or over a weekend, their fatigue could impact the quality of the test and report. And that is assuming the testers will work the necessary hours to complete the test. In many cases the SoW includes a clause that places the responsibility for these types of delays into the hands of the client and does not require the testing team to work past the end of the scheduled test, even if testing tasks are incomplete.