I was not a security personnel at the time of deployment; however, I was the network personnel displaying an interest in security. Therefore, I was assigned the task of installing the email gateway. Technically, the setup was simple. I connected it to the network and redirected all emails to that gateway. Once this was done, the installation was complete.

On a scale of one to 10, with 10 being complex, the initial setup is about a four. It's not that complex. But that's what I meant about the interface. You've got to jump around from place to place to do it. It does have some good menus, but a quick wizard is something that would be nice, where you could just walk through it, and not have to jump between different sections of the menu.

The original deployment took about half a day, if that long. There were probably another eight hours' worth of work on my part going into it, getting familiar with it, and finishing some things here and there.

When they went through it with us, we hit the high points and the main things. I did most of the connecting it to Office 365. Once you do the main things, you always need to go back and you look for those little things that might help you. A little tweak here, a little tweak there — sensitivity settings. So I spent about another eight hours going back and reviewing everything and making myself feel comfortable that it was actually doing what it was supposed to do. There were probably another eight hours over the next couple of months after that, watching the reports and spending enough time with the reports to make sure that it was operating the way we wanted it to.

In terms of our staff involved in deploying and maintaining CES, it's me and there's a junior infrastructure engineer who works with me.

Cisco Secure Email's installation was straightforward. We discussed with the integrator, designed the implementation and tested the product. 

The deployment model varies a little bit. In Portugal, some sectors still rely on on-prem solutions, but we are trying to build awareness that the new solutions relying on the cloud are better for the customers because they don't have to worry about getting new patches and new security updates and patching the infrastructure. They only need to rely on having a service that is provided by Cisco for having the best security. They don't have to worry about the maintenance of the platform itself. The cloud provider that our clients use varies. We work a lot with the banks and financial organizations in Portugal. They are historical customers that don't want to go for public cloud solutions. They still rely on on-prem solutions. They have evolved to having virtualized solutions instead of appliance solutions, but they still rely on having mostly private cloud solutions. They use local providers. We are seeing a shift to global providers but not with all of them.

It's a very modular solution. We have some customers who have deployments all over the world. We clusterize the solutions in each of those locations, and then they connect them with the global management solution. We can manage all the operations of the different clusters spread around the world from one site. It's a very good solution in terms of redundancy even in different geographies.

It's a very easy solution. You can go for a very customizable environment, but usually, for the day-to-day needs of most customers, it's very easy to deploy. You can just customize the options to make it more secure for a customer's environment.

The initial setup is straightforward. Cisco does a very good job of onboarding customers and setting it up so it's very much ready to go based on some fairly standard settings from Cisco's point of view. 

The deployment took only a few hours. Even at my previous organization, it was very quick. Once it was done, we changed our MX records to go to Cisco Secure Email Cloud Gateway instead of Office 365. From there, email went from Cisco Secure Email Cloud Gateway to Office 365. It was pretty simple. We had control of our DNS so it was very quick and easy for us to change the records and get our email flowing through Cisco Secure Email Cloud Gateway. We could see the benefits straightaway. We could see just how much volume was coming in, e.g., in my previous organization, we had something like a million emails per month, of which eight percent would be delivered to our end users.

In terms of switching from one solution to another, it's seamless for the user. They are not seeing the downtime because they're connected to the local Exchange Server. Therefore, they're not seeing the upstream components. There might be a slight delay in terms of the MX records globally, but that is, at worst, 24 hours. So, there might be some delayed emails, but that's probably the only thing. Once we had switched over, we received positive feedback saying, "Hey, what have you done? It's been fantastic. You've reduced the amount of spam messages we used to get."

The initial setup is not that easy. We needed experienced engineers because FTD is a new technology, especially if you're used to VMware or other on-box solutions. Cisco provides both on-box and VM solutions. However, deploying the FTD with the on-box option requires managing two separate operating systems: the FXOS and the FTD. It's not the most user-friendly process, but once deployed, management is quite easy.

You can use the FMC to manage all Cisco security products from one place, making management convenient. However, deployment is still a bit clunky.

The initial setup is straightforward.

Migrating to cloud systems could be challenging. 

The migration to the cloud email security was complex because we have a lot of customization. We needed to reevaluate some of the policies that we were applying via the email security. But technically we had more difficulty previously because we didn't have the premium support. We had to read a lot of documentation and experiment. Now, with the premier support, it's easier.

We re-created everything in the cloud solution. We re-evaluated everything when we migrated. There were some things we didn't migrate, while some new things were created.

It took us nearly one year for all the integrations and the migration to be complete, from the initial evaluation of the new product to the end of the migration to CSE, when it assumed all the email traffic for our organization. We didn't have any particular problems with downtime during the migration. That time includes analyzing, configuring, and improving things in production.

Our team that works directly with Secure Email consists of five people who are configuring the tool.

The product's initial setup phase was easy.

The initial setup is straightforward. That's one of the main USPs, the deployment of these products. It takes hardly 20 minutes to deploy Umbrella over a network. And with email security, it's less than a one-hour job. After deploying, the fine-tuning part comes. That comes under the policies, so I don't count that under deployment. The next step will take another one or two hours, but not more than that.

When deploying the solution, we first go on a call with the customer, understand their pain points, and understand their existing network. We have to analyze the scope of work before deploying. Depending upon the existing setup the customer has, we make our steps. "Is there any prerequisite required? Are there any virtual appliances needed in the network to be deployed?" Accordingly, we will plan our activities. In a two or three-hour call for the first session, we have to define what we have to cover, and in the second session, we have to define the success criteria. The deployment is not a template. It changes from customer to customer.

The initial setup is very straightforward, but a new person needs to be trained to use this solution.

I rate the ease of setup a seven or eight out of ten. The deployments takes one to two weeks.

I wasn't part of the team from the beginning to the end. I came when they were almost done. It was complex but also very interesting. It took two weeks or so if I'm not mistaken.

For the setup, you need to look at the low-level design and the architecture, and then you look at the network interfaces, listeners, routes, default routes, etc. If there is a way they can come up with step-by-step information about configuring it, that would really be nice. The guide right now is too cumbersome and bulky. If there is more straight-to-the-point and procedural information, it would be better. 

I've been involved in the lifecycle management of it and upgrading it, so I have experience with that. It has worked well with no impact on production or something like that.

The upgrade process is quite straightforward. You just have to ensure that you have everything prepared for the upgrade.

The setup is quite complicated. It took us one week to deploy. 

The initial setup has medium complexity. I rate the process a five out of ten. We follow the Cisco guidelines for deployment. It requires two executives to conduct the process.

We have deployed Cisco Secure Email both on-premises and in the cloud. One can use it as a private cloud solution or a virtual appliance in a cloud environment. The implementation and configuration process, including the dashboard, was user-friendly and straightforward. Along with it, the on-premises deployment was easy. It took less than an hour to complete.

Based on my knowledge, its implementation was fast, and there were no issues when it was implemented.

It ended up being a really easy setup for the Cisco cloud product. I was pleasantly surprised how much was already ready for you out-of-the-box.

I found the setup to be straightforward, as someone who was familiar with the management environments. If I had not had the experience with it, there would have been areas that could use more documentation to explain what different sections of the product do. But I had been using it for a long time, so that was not an issue. But I could see that is an area they could put more into. We also had a technical contact available to us for when getting started, to whom we could reach out. But it would be good to add in some more entry-level documentation.

As far as the policy setup goes, our equipment was end-of-life and we weren't at a version that we could migrate from. So we decided to do greenfield for the setup and we're actually happy we did because Cisco's default setup on its cloud product, when they brought up a new blank instance for us, had a really good framework for rules, et cetera. We copied in exception lists and the like from our existing setup and we were up and running in an afternoon.

When we went in, we initially did it as a trial, because they offered a 30- or 60-day trial. We did that to see if this was what we wanted to do. We ended up poking around in the environment a little bit first, because the whole thing was an unbudgeted change for us. When we moved over to Microsoft we found we were having all these issues. We put some resources into trying to resolve them but we saw there were deficiencies in Office 365, when it comes to the filtering of email. We started the trial with Cisco to see if going back to them and their cloud would solve things. We liked what we saw and decided to move everything over. The grass really was greener on that side.

The downtime involved in the migration from Cisco's on-prem solution to the cloud email security was minimal, about 15 minutes. The downtime aspect wasn't especially important since we did it after hours. It's emails, so it's not like anybody was going to notice that it was down for that amount of time.

The learning curve involved in migrating from the on-prem to the cloud email security was pretty easy. The environment really is very similar to manage in the cloud. If you look at the management consoles that you're used to seeing on-prem, and you look at the ones in the cloud, about 99 percent is the same. There are some things that are unavailable because Cisco is handling the software upgrades, but almost all of it that you had on-prem is the same. There are a few extra steps to getting into the command line, they're a little bit weird, but all the policies are identical to the on-prem method. There's not much learning curve involved in switching.

Overall, the migration was massively easier than I expected it to be. We did it on a Sunday afternoon and it only took about three hours.

For the initial deployment, we might have spent a week getting it up and running. Then, we went for a day or two to training.

There wasn't really any downtime involved during the migration from our on-prem to Cisco Cloud Email Security, which was important to us. We didn't want to interrupt email flow. So, we prepared it, then there was a cutover. 

The migration from the vendor’s on-prem to Cloud Email Security wasn't too difficult.

The initial setup is easy. It starts with the VLS for Open IT. Initially, the host access table is there in the front end. Based on that, we can filter out traffic with IPs from the scale of -10 to +10 if it applies. If you want to whitelist an IP, you need to check the IVRX code. If that code is okay, then we provide a list based on the organization. 

It's a bit easy to handle Cisco Secure Email; it's not that difficult. For the logs, which are in PDF format, it's not hard to read them. We don't need Wireshark much to analyze the logs.

Usually, it's GUI-friendly, and also, the Relics are there on the GUI. We can create some relics, or it's automated from the backend by the development team. We just put in our initial setup requirements, and based on that, we create a red x rule. Then we can implement it into the message filter, and we can handle whatever we want, whether it's blocking emails coming from spam or anything else.

The initial product setup was easy. However, it was a bit more complex on our side because of some of the rules that we had set up on a previous appliance, which was not Cisco. Trying to match some of those to Cisco was a little complex. We had some consultants help us out with that. Overall, it wasn't too bad.

The deployment took three to five days.

The product's deployment is easy in a cloud environment. You don't need to install it for the Office 365 product. 

There were definitely parts that were straightforward. The initial bring-up of the gateways was actually cloud-hosted and was done primarily by Cisco. There were definitely aspects of it that I didn't even have to touch and it was wonderful. They just did it for me and that was great. 

When I took over administration there were aspects that were definitely easy and intuitive like the basics of being able to set blocks and set allowances when you have false-positives and false-negatives. It kept the basics simple. 

Of course, just like with any enterprise technology product, it can get as complicated as you want it to. There are a lot of granular controls that you have the ability to tune, but doing so requires more in-depth knowledge and more in-depth training and making sure you know what you're doing. Otherwise, you can end up doing things you never intended to do.

The initial bring-up, the initial switch from Proofpoint to Cisco, was pretty quick. We had a little bit of redundancy but the overlap was a couple of weeks at most. I would condense it down to about a week, because there was one week where it was mainly status updates. As far as tuning the appliances and tuning the filters go, that's an ongoing process for me. I still do that today.

In terms of implementation strategy, you want to minimize downtime, so it's important tor run in parallel for a little while. Thankfully, we had the ability to point some test traffic to the new appliances before moving the rest of the enterprise over. So it was:

• run in parallel
• send test traffic to the new Cisco gateway appliances, to make sure that things are flowing the way we'd expect them to 
• and then we staged it a little bit more. 

We accept emails from multiple domains and we moved our primary domain last. We started by moving over some of the lesser-used domains to verify things were okay and then moved over the primary domain last. It was a typical implementation that most people have: Run in parallel until you verify, and then move everything over.

Regarding staff for deployment and maintenance, right now it's just me, but it's unwise to have just one. What happens if I get hit by a bus? To do this properly you would need at least two. 

In an enterprise you end up with a myriad of email hiccups. Email hiccups are one of the most common. Being on the information security team, you have to look at it in a multi-faceted way. That means I'm not just looking at the flow of data. I'm also having to analyze the contents of the data and then start to determine whether I need to dig further into it to see if this particular message possibly went to multiple recipients. That's the investigative piece. The administrative piece is a given, but then you also have an investigative piece on top of that. That can be a lot to do, it could be an overwhelming amount for a single person to try to do. That's especially true when something does happen. 

One person is probably going to be consumed with trying to do all that. Is it doable? Sure. Is it advisable? No.

The initial setup was simple and easy. You open one screen of your on-premise Cisco ESA configuration and you copy-paste it to the other screen of your Cisco ESA system in the cloud. So the transition was very easy.

It took around one month to implement. 

The strategy was to get rid of the physical servers and move to the cloud.

I have deployed some 100 email security appliances, so from my side the deployment is very intuitive and simple. We don't have difficulty deploying it in our data center.

We create our own template in our virtual environment, and from this template we are deploying further security measures. To deploy it virtually takes about 30 minutes and after that the customization for our customer could take from half an hour to a few hours, depending on how complex it is.

We have five to 10 people involved in deployment of the solution. The people who work with it are technicians, the system administrators, administrators, and people in IT SecOps.

In terms of updating the appliance, once we set it up, it completed by itself. It was automatic mostly, but we took one night's worth of downtime. It completed in one to two hours. There were two people involved in doing the update.

We had a cluster set up, one to five devices, three in the DC and two in DR. It took only two people. For me, it was complicated. The other guy was very experienced on it. He had so much implementation experience on the appliance and he was able to guide me through it.

We did the DC first and failed over to the DR. Then we failed back and did the DR.

The initial setup was straightforward, but very lengthy, because it powers up most of the options from the email filtering solutions. While it is good, it will take some time to implement all the features, compared to other solutions. 

It is very simple to set up, but we decided to set it up with exceptional cases. Cisco is more flexible compared to other solution, but it could still improve, especially in the area of ruling logic and enhanced communications. With some other email security products, we can have very complex conditions which we can filter out. This is still not available with Cisco Email Security.

It takes a minimum of a month to build the setup. However, for a good set-up, it will require one year to put in place all the options in place. We had to understand how the emails flowed. 

The solution is cloud-based. The initial setup is straightforward.

Cisco Secure Email's installation is neither difficult nor simple. I rate it a seven out of ten. The tool's deployment takes around an hour to complete. 

I cannot answer in detail about the initial setup because it was done before my tenure began. In general, it is a complex configuration.

Regarding an implementation strategy, it is best to define basic policies that deal with malware and spam-blocking which apply to the whole organization and then configure specific policies for individual and departmental needs.

Deployment shouldn't take more than a couple of hours for a team of two engineers.

The initial setup is straightforward. There are two flavors. There's the cloud-based and the appliance. With the cloud-based solution you just point your email server to the IP address in the cloud. With the appliance, you just install it into your rack and connect it to the Exchange Server. The cloud deployment takes about ten to 15 minutes, and the appliance, because you have to install it, takes about 60 minutes.

It requires just one person for deployment. It doesn't require anybody for maintenance. You just set it and go.

The initial setup was complex because I have two sites with physical clusters. and i made it alone during the working hour without interruption.

The length of deployment will depend on the complexity of your infrastructure and your knowledge.

We are using both cloud and on-prem versions. The deployment took less than two hours. We keep a backup of the configuration ready. Once we implement the server, we just put in the configuration and start.

The initial setup was pretty straightforward. The basic mail policies were very easy to set up, but tuning the email flow and blocking certain things according to particular requirements takes time.

The initial deployment took about a week. Our implementation strategy was not to stop the mail flow while implementing adequate security features, including Anti-Spam, AMP, and AV.

Deployment and maintenance requires one engineer, maximum.

The initial setup was very straight forward. Having said that, we had a lot of experience in email systems before we set up these devices. But to get the most out of the functionality of the devices it took us some time to implement custom email filters. These were detecting targeted phishing email, although they weren't called that back in the days when we first got this type of hardware.

This was in the days before it was common to have virtualized systems. The systems we had at the time were probably the type that might have been considered by a small ISP. At the time it might have been Cisco Secure Email Gateway 310 or 320 systems. It was a long time ago. We have had those systems on contract since then. We've regularly upgraded the systems when the contract has been renewed.

We've had the systems configured in a cluster where the cluster spans more than one email gateway. Email gateways are located in different countries, so although we have different places where the email can be delivered to Fugro and from where Fugro sends email, the systems are all managed from the same interface and console, even though the systems are in different countries.

Because I had a video walkthrough that I made use of, I found the configuration pretty easy, not so difficult. Also, the prior knowledge of my then-line manager gave me an edge, helping me with using and administrating it.

The deployment I did last was done within five to ten days.

IronPort has been in production before I got the job. They had issues because the configuration was not suited to the business. What I had to do was a clean configuration, reload it, and start the configuration all over again.

I and my line-manager were the ones who were involved. I did a larger chunk of the job. I was the only one maintaining it until I handed it over to the network engineer who took over from me. Maintenance takes one person or two.

The implementation is quite straightforward, but the customization can is a bit difficult. It took us three hours to implement and three to seven days to configure.

Before implementing, we had to design a new program.

We had to configure it, but it wasn't complex.

The initial setup was straightforward. There was nothing complicated. It doesn't take more than two engineers. When it comes to the software, if there is good coordination between a Cisco guy and an email-server guy, the two of them would be enough to implement it.

It was really easy to implement. Even a newcomer joining the company could easily implement it. There is nothing complicated in the device. It can be easily implemented without headaches.

The setup is very straightforward. It's very simple to install. It hardly takes 30 minutes.

There is a strategy for deploying, like determining how many users' emails do you want to pass through it. There is a long document, we call it High-level/Low-level deployment. And after that we, pass emails through from the Exchange Server, incoming and outgoing, to configure the kinds of emails the product should filter.

A deployment requires a maximum of two people: One is a network engineer and one is an Exchange system administrator, so if he wants to he can configure rules according to his requirements.

The deployment was quite easy. We wanted it with high-availability. It wasn't a greenfield, it was just an upgrade. The initial deployment had been done before.

The GUI is self-explanatory: If you want to block emails, you want to erase emails, you do the IP address configuration and what your DNS is. It's pretty simple, a very easy-to-use GUI. If you want to buy licenses, you want to check the status of your licenses, you want to check the status of your box, you want to check the environment, it's very simple.

The upgrade took me about 30 minutes for each box. It was just me involved in the upgrade.