Remediate Shadow IT Rogue Sites with AWS DevOps Security

There are two kinds of rogue websites: one created by external organizations looking to subvert a legitimate website by appearing to replace it and the second is a website created by an internal team without obtaining proper approvals. Today we will discuss the latter and how AWS DevOps best practices can remediate the issue–as told through the story of a technology organization we recently worked with.

The issue: This hardware technology company had recently acquired another organization. As the hardware company began the process of integrating the new company, it became clear that the acquired company had a host of rogue websites that needed immediate attention. Specifically, there were dozens of sites created by marketing (and other) departments without any IT or security oversight. In fact, the issue originally raised itself as the marketing team came to security thinking that one of the sites had been hacked.

The research: Having worked with Flux7 on a different project before, this organization called in the Flux7 DevOps team to help. From this prior experience, the company had built a solid AWS security team that could effectively act as a role model to the new organization’s DevOps security teams. Using this group as a foundation, we recommended several important steps:

1. With the assistance of the marketing team, conduct an audit of all the sites marketing — and other groups — built on their own. This review should result in a comprehensive list of rogue sites.
2. Next, audit each rogue site, finding the security issues with each, e.g. the use of out of date software, end of life OS, etc.
3. Last, communicate to the company at large that there will be a new process and set of requirements forthcoming for anyone in the business who needs to create a website.

The recommended solution: The solution we propose in these situations is two-pronged. First, create an easy-to-use process for creating new websites moving forward, a process that every business group is sure to use. Second, remediate the existing rogue websites.

Easy Website Process
At Flux7 we’ve learned over the years that making security easy actually improves security as people are more likely to work within the security parameters if it’s easy to do so. With that theory in mind, we recommend organizations create a process that makes complying with website security as easy as possible.

For example, we recommend an easy process and set of requirements for business customers when they want to spin up an Amazon site with a policy that directs end users to log into an AWS console where they can request a website, preconfigured with standard infrastructure designed by IT.  Business groups have the ability to customize their website, but not the infrastructure behind it. This policy makes engagement with IT the starting point and helps ensure website security and compliance.

We recommend that the website infrastructure be migrated in its entirety to AWS. Following the Enterprise DevOps Framework(EDF), our suggested approach is to create a landing zone for new services using Hashicorp Terraform, private subnets in VPCs, supporting separate production and nonproduction accounts. In addition, deploy security inspectors like AWS WAF, AWS Config Rules, and CloudTrail into the pipeline to ensure security and PCI requirements are consistently met. Last, injectors in the form of Kubernetes Secrets and HashiCorp Vault should be used to insert secrets like API-keys and passwords to keep services flowing.

For the website template, we recommend using Amazon CloudFront, built-in CIS benchmark recommendations and AWS security best practices to ensure all sites meet security and PCI compliance requirements moving forward. In this case, we also recommended standardizing the website solution using WordPress in AWS supported by best practice security services like AWS WAF. In this way, every website is using the same platform, streamlining security and operational resources needed to manage them. The template is then available to end-users via AWS Service Catalog where they can use an “easy button” to provision a new website. And, only admins with appropriate credentials are able to edit the base website template.

Remediation
With a list of things on hand from the review, the DevOpsSec group knows what they need to remediate for each rogue site. While many of the sites can likely be shut down and the teams asked to participate in the proper process to re-instate their site, a handful may be deemed too critical for this process. In these cases, ask for and access to the AWS credentials in order to access the account and begin fixing the specific issues with each site.

The outcome: Rogue website remediation should be addressed quickly. For example, this company had a goal of doing so within 90 days. In this time period, the DevOps security team should be able to thoroughly audit, shut down and/or remediate all of the rogue sites.

Rogue sites can haunt your security efforts and hamper the effectiveness and efficiency of your DevOps success. These issues can negatively affect everything from IT to marketing, finance, and more. Coupling a culture change with DevOps automation and self-serve IT will enable you to ensure that AWS security best practices are consistently used across your many websites, all of which have the blessing of IT and security.