Moving a service to a cloud provider can be a very beneficial activity (reducing cost, piece of mind, transfer of risk), but it can also create a huge amount of problems if not done correctly.

We will not delve into what SLA and service conditions are agreed on with your service provider. We will focus on the migration process.

Assuming you have selected a service to migrate to a cloud provider, and have selected the cloud provider, even after contract signing, things may still be far from complete. The migration process is the thing that can be very painful and can break the entire service for an extended amount of time. And sadly, the service provider may not be too interested in properly supporting you in the migration process, for whatever reason.

To ensure a successful migration, or at least to be able to 'pull on the handbrake' before disaster strikes, make sure that you check the following elements before driving into the migration process:

• Clearly understand what data from the current service will be migrated into the cloud service - this is crucial from several points of view: If there is migration, you must understand the amount of data can and will be migrated, whether the service provider has sufficient space to accept all data or you'll need to prioritize and whether the format of the data remains the same. For instance, you may be using a MySQL database but are migrating all data into an Oracle cloud service. Also, if data is not migrated, you'll need to keep it available to the users as legacy data.
• Clearly understand the migration process of the data from local into cloud service - if existent the migration of data can vary wildly. It can depend on very complex factors like change of format, structure, proxying etc, or very simple like bandwidth to transfer the files over.
• Understand authentication source of the cloud provider - all your services were authenticated to a data-set within your company, usually a LDAP server or a database. You must understand which data-set can the cloud provider support for authentication, because you may need to recreate your user's accounts and generate and distribute new passwords to them.
• Gather all usage scenarios of the service as it is currently delivered (in house) - there may be multiple usage scenarios for a service that have been introduced through the years, either officially or unofficially. For instance, a mail server can be accessed via POP3, IMAP, MAPI (on Exchange servers), and different users may be using different protocols.
• Confirm which usage scenarios are supported by the service provider - your users may need to be reconfigured in advance or at the moment of migration. You need to understand which steps you'll need to take to maintain minimum outage for the users. This is usually tightly connected to the authentication source and set-up.
• Ensure you have bandwidth - Going into the cloud means remote access. And whatever your in-house service was, you never cared about bandwidth usage and latency over your gigabit LAN, but that bandwidth usage may be very significant. Observe your current network using network analysis tools and learn more about broadband packages that you use, especially their flexibility to quickly increase bandwidth or decrease latency if needed on roll-out time.
• Know who to call - at time of migration and right after that, things are going to be hectic, issues will rise all over the place, and your team will be less than their usual competent self, since they'll also be using a service. Have all of them read through the SLA and the communication and escalation procedures of the cloud contract. This way the issues will be escalated rapidly, and support call will be made much faster.
• Understand your fallback options - any migration can go wrong. In order to be able to continue your original service in such a scenario. Investigate whether your original service will be available during after the migration, and look and test for any risks that the migraiton may leave your in-house service broken. This may be a huge issue if somehow there are problems.
• Make a plan with outage period and ability to go back to your service - before you go into migration, make a plan for the migration, in which you'll define the migration period start and finish times based on testing results. The entire period of migration should be planned as  downtime, and the source service should be in a 'frozen state' (no new entries in it). The reason for such a downtime is two-fold: Even if the migration is online, if anything goes wrong, you are under less pressure to fix it, and by creating a frozen state of the source service creates a point-in-time to which you are prepared to revert in case of trouble.
• Inform everyone of the pending change - spread the word, the customers should be well aware of the change. Informing everyone is about people being able to plan and adapt if the service is out, but it also helps you and your team - you'll get more feedback and discover overlooked items, and during the crunch time the users will give you more breathing time instead of jumping on your throat because their service is not working. 

Migrations are a very stressful time for everyone, and hopefully the above points will help both you and your customers survive them in a smoother manner.

Talkback and comments are most welcome

Related posts

Management Reaction to Failed Cloud Security
 Security Concerns Cloud “Cloud Computing”
Maintaining quality in outsourcing telco services
5 SLA Nonsense Examples - Always Read the Fine Print  

For the man who illustrated our imagination, and made me personally read more...

rest in peace, Ray

Ray Bradbury, 1938-2012

Phone call social engineering is considered the easiest methods of social engineering: It does not involve personal contact, and leaves little in way of electronic trail (e-mail can leave much more eletronic trail if not approached properly).

In the past months Shortinfosec had the fortune to review an social engineering attack performed by a pen-test team on a company. While the pen-test was considered a failure by the client, significant elements of the attack point to open issues with the client. Publication of this information is based on the provision all information regarding the pen-test client and provider location, business and identity to be unidentifiable.

The attack
The social engineering attack was performed over a phone line, not even being in the same city as the client, with the pen-testers using publicly accessible lines. The targets of the attack were chosen from social networks.

The attack was three-stage:

1. Collect information about order delivery process (delays, timing etc...)
2. Collect information about current order in pipeline (order prepared but not delivered to customer)
3. Divert order to different address.

 The attack was performed by multiple phone calls, which created contact with multiple targets. Each call was a probing attempt to collect as much information possible. The first and second stage of attack was targeted at the same targets but with several days delay between stages. Two persons performed all attacks.

• In the first stage of attack, the attackers simulated a disgruntled customer, which insisted on getting details on the process as his delivery was not proper. Approximately half of the targets responded were either compliant to explain the process, or were unable to reach the account manager and proceeded to divulge information to the attackers.
• In the second stage of the attack, the attackers approached targets that were deemed 'soft' - that were most compliant and divulged most information. They misrepresented as persons from multiple client companies, until they received information of a current order in pipeline. A minor number of targets responded with required details, simply because they most targets did not have access to order information. 
• In the third stage of the attack, the attackers again approached the 'soft' targets attempting to divert the order from pipeline to a different delivery address. Most targets did not have the authority to change the delivery address. The attackers reached a target with appropriate authority, but that target contacted the real client while on the phone to verify. The client denied any change, which caused the all kinds of alarms to go off. At the end, police were notified immediately, and the pen-testers nearly ended up in custody.

The review
When investigating the approach used by the social engineering attack, we found missteps in the following areas:

• The process research - the failure of the attack had one primary reason: The requested redirection address was outside of the free delivery area, and the targeted person actually sent out an electronic invoice to the real client for the redirection. This invoice was rushed by the client's accounting department since it was for an outstanding order, and immediately disputed by the client, thus exposing the attack. This shows insufficient research of the process
• The selection of targets - the targets of the attack were selected purely by one criteria: anyone who has a public information regarding their employment at the pen-test client on social sites. This approach is easy, but there were very little criteria of how useful these targets are in the further stages of the attack, and how they tend to react. This caused multiple calls of relatively low quality information or response in the first and second stage - thus spreading the attacker resources thin.
• The selection of faked client - the faked client was not researched, and was selected by random from the information received in the second stage of the attack. The client should have been approached to research its process. A contact center channel would be an excellent 'cover' for such a task. This is especially true since the pen-test client operates via a phone channel. But instead researching the client through impersonation of an anonymous service like an Appointment Setting Service, the attackers merely dropped a name of a client. This lack of research, combined with insufficient process research caused the inability of the pen-testers to prevent the invoice reaction.

Apart from these missteps, the actual amount of achieved information gathering was quite interesting: The attackers collected information about business process, customers and current orders. Even without being able to redirect an order, the collected information could be valuable for sale to competitors or for publication to discredit the business.

The conclusion
This particular case was deemed by the pen-test client as a failed social engineering attack, but that is obviously a purely formal treatment of the outcome.
The missteps in the process which were identified are not uncommon in a pen-test scenario, where deadlines are short, and results need to be produced by the pen-testers on time and under budget.  The entire process and results has lessons for both pen-test client and pen-test team:

• The pen-test team should reserve sufficient time in the project schedule for investigation, which is crucial when playing with the emotions and reactions of human beings. 
• On the other side of the fence, the pen-test client is still quite exposed, with information leaking left and right, which was  proven by the amount of information collected by a pen-test team with relatively small amount of research.

Talkback and comments are most welcome