Once it was determined that SOC2 was business critical, Chief Information Security Officer Clarke Rodgers says he analyzed the different ways of getting there and finally determined that moving to the cloud was the most efficient path. Rodgers recently shared the story with Network World Editor in Chief John Dix.
Let’s start with a thumbnail description of the business.
At a very high level SCOR is three businesses in one. There is a life reinsurance entity, a property and casualty reinsurance entity and an investments group. In the reinsurance business we essentially insure other insurers. So, for example, if you take out a life insurance policy with your direct insurer, they will take so much risk on your life and then cede the rest of the risk to reinsurers.
SCOR Velogica falls under the SCOR Global Life Americas division and is both a business unit and a Software-as-a-Service product offering. The product Velogica is an automated life insurance underwriting engine, so if you sit down with an agent and fill out the forms, on the backend their systems connect with Velogica which runs that information through several algorithms and data providers and comes back and renders one of three decisions for the agent: accept this person, deny this person or refer this person to a human underwriter to make a final decision.
And you were providing this service from your own data center? What prompted you to move to AWS?
As you can imagine, in the life insurance business we’re dealing with some of the most sensitive data out there -- health records, prescription drug history, visits to the doctor, information about whatever ails you – so we have to go to great lengths to protect it, not only for the end user (the insured), but for the companies we support and do business with. Since we go to such great lengths to protect this data, we wanted to get a third party attestation, demonstrating our competence in securing said data. In our opinion, the SOC2 Type 2 accreditation is the premier third party assurance report for our industry. The pursuit of that accreditation is what prompted the move to AWS.
SOC2 is based on a framework of trust service principles, defined by the AICPA, that touch on all or some of the following -- security, confidentiality, availability, processing integrity and privacy. Once you address the requirements, third-party auditors come in and assess your service to determine if you meet the criteria. We felt the three that would add the most value to our business and our clients were security, confidentiality and availability.
So, you saw SOC2 as being important to your business and started looking at ways of achieving that?
Correct. You typically start with an assessment of what your current environment looks like. You can either do that yourself or bring in an auditor, which is what we did. We found there was some room to improve, as most all companies find, and then we looked at the best ways to remediate. Looking at our systems, we found some of the remediation would affect other parts of SCOR and realized it would be difficult to enforce that level of security on parts of the organization that didn’t need it.
So we started to say, “What if we carved out this business from a technical perspective?” We could still use the core backend services, like HR and Legal, but from a pure IT and security perspective, maybe we could carve it out and achieve a more efficient path to SOC2. Could it be as simple as getting a different colocation facility and just putting all the Velogica assets in that? Do we look to the cloud? What else could we possibly do?
It became clear very quickly that going to the cloud was the path of least resistance, and of the cloud offerings out there, AWS was the clear leader based our research.
Once we had determined AWS seemed the right way to go, we created a rough draft of what our AWS environment would look like. But the issue we ran into -- and I think a lot of companies have the same problem – was a lack of AWS-certified cloud engineers on staff. Cloud is distinctly different, so you really need to have that expertise to guide you through what is and isn’t possible. Typically, companies like ours have a couple choices. One is to staff up internally, by bringing in people who have the certifications and expertise, or two, train your existing staff.
But under the time constraints we had imposed on ourselves to achieve SOC2, training up locally or hiring additional staff wasn’t going to work. So we started looking for third-party professional services companies that were perhaps AWS partners, who had the staff, the expertise and who had done this before.
We ended up evaluating three vendors, and 2nd Watch was clearly heads and shoulders above the others. They had done migrations similar to ours, they had done more advanced migrations, larger migrations, and they really understood the cloud. That’s what we needed.
Once you selected 2nd Watch, how did the migration progress go?
We signed the contract in the Fall of 2014, the initial analysis was probably completed in December, in January 2015 migration of the test and development environments started, and QA happened in the Spring, all while building out the core infrastructure … Active Directory, email and end user computing, network security, AWS Security Groups, etc. We tested the disaster recovery environments, had a penetration test performed by a third party and then began migrating our production data in June. We flipped the switch at the end of July and were offering our services in full production to clients from AWS.
Can you give us some perspective in terms of how big a job it was?
Approximately 200 compute instances were created in AWS to mirror our on premise environment and then data and applications migrated accordingly after that.
As you probably know, there are a couple of migration strategies to the cloud. One is coined as a “lift and shift”, where you have minimal disruptions to the way your application works and you just take it from on-prem and place it in the cloud and it’s virtually the same as what you had before, just on another provider’s infrastructure. The other option is to break down your application and infrastructure into core components that can be easily managed by your cloud vendor’s service offering and then exploit some of their unique capabilities to your business’s advantage. In AWS’ case this includes services like simple storage service, elastic load balancing, auto-scaling and multi AZ, high availability architectures to name a few. We went with the former because we were under time constraints, but now that we’ve been in AWS for a bit, we’re starting to exploit some of those native capabilities and make things more elastic, more efficient, and more durable and highly available for our platform.
But you pulled off the migration pretty quick.
The way Velogica works, it was an all or nothing experience when we flipped the switch. Our secret sauce on the backend can only really be run securely from one location. That’s why testing was paramount. We had a third-party company do a full penetration test of the AWS environment, just to make sure that not only was the AWS platform providing the security we expected, but to ensure the controls we put in place with 2nd Watch and other vendors were working as well.
One key piece to note: As we were performing our testing in AWS, we proactively reached out to our clients to tell them what we were doing. We are contractually obligated to tell our customers where their data is, so we took the opportunity to contact our clients and explain why we were moving to AWS and how it supported our SOC2 efforts. Beyond the security benefits of moving to AWS, we demonstrated to our clients the higher level of service we’d be able to provide via the new platform. Ubiquitous encryption, highly available web services, durable storage and a robust disaster recovery and business continuity solutions all made for a convincing presentation.
Not one client hesitated. There were a couple that were not as familiar with AWS, so we had to educate them. But no one hesitated a bit, and a couple are now actually starting to look at moving some of their operations to AWS as well.
Did you have your SOC2 accreditation right out of the gate?
No, you don’t get it right out of the gate because you have to be able to demonstrate that you’ve been running successfully for a period of time. We had our SOC2 Type 1 issued in September of 2015. The difference between the SOC2 Type 1 and SOC2 Type 2 is, not only do you have to show that you’ve met the criteria, you have to show you’ve operationalized it and continue to do so over time. When our auditors come in at the end of the quarter we’ll have a six-month period of running with the SOC2 controls operationalized, and what they’ll do is audit how we’ve achieved certain criteria. Going forward this audit, and issuance of the SOC2/Type2 report will occur on an annual basis.
Any surprises or hiccups along the way? Any lessons learned that you would share?
I go back to the decisions we had to make. Do you lift and shift what you have, or do you try to build it out cloud-native from day one? There are good points to both of those and I think companies that are going to explore this move really need to give that some thought. We had the time constraint since we wanted to get SOC2 in place quickly, so that really drove the decision. Now that we’ve been in AWS for a while, we’re going back and making things more efficient and cloud native. The debate is, would we have been better off doing that on the frontend? Maybe yes, maybe no, but we wouldn’t have achieved our SOC2 goals on time, failing the business objective. It’s a topic people really need to spend some time thinking about when planning their cloud migrations.
The other thing is, and this is specific to AWS, they innovate at such a pace that it is difficult to keep up with everything they’re releasing on any given day, much less over time. There were some things we engineered around because they just didn’t have some functionality. Had we waited six weeks, they had that functionality in place.
One shouldn’t complain about the speed of innovation in the cloud because it always seems to be for the positive, but we did have to engineer around some things and now we’re pulling those things out and taking advantage of the native tools, which again is great, but it was still an engineering challenge I would just as soon not have gone through. Perhaps this is the early adopter’s dilemma!
How would you quantify the benefits all told?
The security benefits are fantastic, because I now effectively have an extended security team working 24/7 on my behalf. I have AWS’ security team working for me ensuring that its core infrastructure and services are running in a secure fashion, I have AlertLogic (our managed service security provider) security analysts watching, alerting and reacting to any threat within our part of the AWS cloud, and I have 2nd Watch’s security team managing the patching, antivirus updates, firewall rules and reporting. All three components work together seamlessly and act as a force multiplier to the SCOR Velogica security team.
This allows our employees to narrow their focus on the Velogica platform and let the experts who live data center management, network management and cloud management do it for us. Our business is making sure the Velogica application is providing what our clients need and that we are securing it appropriately. That’s one of the huge benefits of moving to the cloud, the ability to focus on your core business and your core business only.
Is performance the same, better, worse?
The performance is the same or better, depending on what service we’re talking about. The ability to spin up and turn off instances when we don’t need them is huge. There is significant cost savings in our development efforts and I imagine this would be the case with many companies. You’re not developing 24/7 because your employees need to go home at some point. In an on-prem world you’re still paying for those compute cycles, you’re still paying for those licenses, you’re still paying for that network bandwidth at 2:00 in the morning when nobody is working.
We can turn off our development and test environments programmatically, and have them come on when we want to, and that saves a significant amount of money because they can be off for hours of each day and/or the entire weekend. That’s just not something you can do in the on-prem world.
Everyone talks about the cloud making them more nimble. Any benefits on that side?
Absolutely. We can serve our clients from AWS’ East Coast region or their West Coast region and, frankly, any other region AWS develops. So, if we decide to expand the Velogica platform internationally, if AWS has a presence there it would be a matter of clicks to recreate the environment in, for example, the Frankfurt or Singapore region and keep client data local in accordance with local data privacy laws. That’s huge. We don’t need to reengineer things from an infrastructure perspective; that’s already taken care of. We can just templatize our environment and duplicate it in these other regions.