1C L O U D G U A R D R A I L S

Better Secure than Sorry:A Guide to Basic Cloud Security No Company Can Afford to OverlookBy Phil EschallierChief Technology Officer, RCH Solutions

GUIDE

2C L O U D G U A R D R A I L S

Public Cloud: The New Operating SystemWhat is a Public Cloud? In case you missed it, a Public Cloud is a set of 3rd-party managed infrastructure and computational services that has Application Programming Interfaces (APIs). If it doesn’t have an API, it’s just someone else’s computer (physical or virtual). Today, the major players in the space—Amazon Web Services (AWS) and Microsoft Azure (Azure) as market-share leaders—are so comprehensive in service and APIs, they’re becoming the new Operating System.

Businesses across all industries are integrating the Cloud into their overall I.T. strategy—and for a good reason. The Cloud provides seemingly infinite scalability, increased flexibility, and maximizes collaboration while retaining its value compared to other on-prem options.

SECTION 1

Why take the time to write yet another article on Public Cloud security?

Let’s answer this with another question, “Aren’t you tired of the same repurposed content posts that presents what’s now become a commodity?” This offering, admittedly more narrative in style than a technical paper, hopes to offer a holistic high-level perspective on securing business in the Public Cloud.

Authors Note: The tone and terminology are intended to be Cloud-agnostic. Where specific services or features are presented for clarity, AWS terms are used given AWS’s prevalence in the Public Cloud market.

3C L O U D G U A R D R A I L S

Similar to 10 years ago, when debates raged about whether Windows, Mac, or UNIX were best for businesses, the prudent approach to Public Could remains a diverse mix of services.

Combatting LegacyEven today, many companies and I.T. leaders fear the Public Cloud is not secure. The reality is, the granularity of controls in Public Clouds, as well as the ease and speed at which these controls can be refined, enable a properly configured Public Cloud to be very secure (even more secure than conventional data centers). If this were not the case, Cloud providers would not be able to stay in business.

Nonetheless, the following list of Security considerations should be useful to those in the midst of designing or deploying their Public Cloud.

Ensuring Cloud security and excellence is not a part-time job; human resources should be empowered to focus exclusively on Cloud initiatives.

4C L O U D G U A R D R A I L S

Facets of Public Cloud SecurityWhy is Information Security important? While primarily a rhetorical question, the answer is because your business, along with its viability and continuity, is essential.

Right Team PeopleThe level of accountability, skill, and perspectives held by those managing and supporting Cloud efforts is critical.

Information Security is not just the responsibility of Security professionals alone. Business owners, executives, and all relevant team members with Cloud access share a collective responsibility to prioritize Security. Ideally, these teams remain relatively small in terms of member count and include a mix of strategic and critical thinkers with leadership, planning, organizational, and cross-functional I.T. skills.

In Public Cloud terms, these individuals should form the foundation of a dedicated team of professionals known as the Cloud Center of Excellence (CCoE). For something as important as secure, high-performing business platforms, value rarely comes in the form of the lowest bidder (and unfortunately more than a few Enterprise attempts at a CCoE miss out on the “oE”), so don’t cut corners. Team members should not only be dedicated to the company, but also to their role in executing the strategic mission of the CCoE. In other words, ensuring Cloud security and excellence is not a part-time job; human resources should be empowered to focus exclusively on Cloud initiatives.

The Sources of Risk Understanding sources of risk enables you to prevent them from becoming a reality.

In planning for your Public Cloud security needs, it helps to understand the risks. Specifically, who are the enemies, and why would you be a target?

Like it or not, the Internet is a dangerous place. Along with many modern businesses and an expanse of individuals spanning the globe, the Internet is home to hackers. (Once upon a time, the term “hacker” was used for highly skilled I.T./software types, while the term “crackers” was

SECTION 2

5C L O U D G U A R D R A I L S

used to describe those who would use their hacking skills for nefarious purposes, but I digress). Hackers, whether freelance, corporate-sponsored, or government-sponsored, are a threat to all things on the Internet—and the Public Cloud is on the Internet.

However, what about other sources of risk? Things like non-malicious human error within your organization, or those anonymous Internet residents with too much spare time. In other words, everything is at risk and the risks span the gambit.

Another critical task for understanding risk is evaluating what you seek to protect. For most, it’s data. Stolen data, once out of your control, may be the end of your business. However, with the proper controls, lost data can often be restored, costing only money and time. Do you have controls in place to know if your data has been modified or corrupted?

It may be that your data is a commodity and readily reproducible, and it’s your services that are Intellectual Property. In this case, the risk may not be theft, but denial of services (for example, a Distributed Denial of Service (DDoS) attack). Moreover, your platform likely has value to serve as a launch-point for hackers to attack others.

A Solid Contingency PlanBeing prepared to respond to the worst-case scenario is one of the best ways to prevent it from happening.

Yes, “an ounce of prevention is worth a pound of cure” (per Benjamin Franklin), but we have to plan for the worst case. What is the worst case? It’s [catastrophic] data loss, Zero-Day events (a vulnerability or exploit known only to attackers for which there is no patch or fix), infrastructure or platform damage or loss, hackers, malware, viruses, ransomware, etc., or any of the like concerns that keep business owners and I.T. managers awake at night.

Taking it Further• Avoid the M&M Security Model –

This model is the name for security implementations where it’s hard and crunchy on the outside but soft and chewy on the inside. In an I.T. context, this means that once the perimeter is cracked, it’s unfettered.

• Be mindful of the Full Stack – Best practices for Infrastructure and Platforms are an absolute must, but the same rigor has to be extended to the application and data layers. For example, a recent ‘event’ with a customer saw an Internet-facing application become compromised, a surprising outcome given all the Cloud security and tooling in place. After some discovery, it was determined that the application wasn’t properly written.

6C L O U D G U A R D R A I L S

Planning for such worst-case scenarios means having robust and viable data backups, a [tested] Disaster Recovery plan (even for the lower priority data and services), skills, or partners positioned to help mitigate nefarious acts or bad actors.

In terms of services, this is likely to include commercial backup capabilities having “restore times” that meet business needs (we can explore technology options in a different write-up). In the event of a real catastrophe, Disaster Recovery planning and support services are vital, whether physical/virtual/Cloud or spin-up/pilot-light/other. Data Backups and Disaster Recovery can get expensive, but we have to ask, “How much would it cost in money and time if rebuilding from scratch?”

In terms of malware or ransomware, we want a solid firewall and antivirus-style protections. However, in the event of a compromise, you need to have the skills or resources available to combat infections or be prepared to recover impacted services quickly. These recovery plans cannot be understated. And “yes,” this is a Cloud article but I am alluding to physical/on-prem here as well simply because, in the event of an emergency, a comprehensive services restoration plan is invaluable.

The Shared Responsibility ModelCombining team and vendor accountability expectations for better results.

The “Shared Responsibility Model” is an age-old concept based on splitting duties to achieve a goal. In terms of Public Cloud, this model means your Cloud provider takes responsibility for their service, and then you take responsibility for what is layered on top.

More specifically, the provider takes responsibility for Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). You assume responsibility for the configuration of Public Cloud services, as well as your applications, data, and the like.

Full Stack SecurityBecause a chain is only as strong as its weakest link.

Full Stack Security is what the name implies: A security focus covering the entire solution stack. For the Public Cloud, this is an extension of the Shared Responsibility Model. Starting with the recommendations you’ve read elsewhere, you should also consider and/or implement:

• The Least Privilege Model – Provide the needed access and only the needed access.

7C L O U D G U A R D R A I L S

• Multi-Factor Authentication (MFA) – Using secure token generators or apps on personal devices as a second level of authentication beyond passwords. Passwords can be cracked; security questions can be extracted or socially engineered; biometrics are promising but not bulletproof, so adding a second level to authentication is strongly advised. If too expensive to do this for all users, consider that MFA for privileged access is an absolute must.

• Encryption – Do not store or transmit data in clear-text, encrypt it. Encryption is a core feature of all major Public Clouds that only nominally impacts performance, so it should be used to protect your assets and services. Be smart, use a quality encryption, and decide who will manage the underlying keys.

• Secure Architectures – This topic is probably worth several books but in-short, leverage network, data, and application models that encapsulate assets.

• No [unnecessary] “outside-in” access – It’s tempting, for example, to set up a way to check a platform or service from home, but if you can get in, what makes you think that others can’t? Even if you restrict access in this example to your home IP address or your personal keys, is your home network uncrackable? Be smart, use a sanctioned, and tested VPN access method for all access.

DevOpsDevOps, DevOps, and more DevOps. But what is DevOps?

Unfortunately, there are too many definitions of the term DevOps.

Primarily, DevOps is a practice that combines software development and information-technology operations—the bridge between aiming to reduce lifecycle times and iteratively deliver features or updates. One tongue-in-cheek definition of DevOps is “the stuff that developers don’t want to do,” but perhaps the better perspective is “the stuff that developers shouldn’t be doing.” One essential facet of DevOps is that it is “continuous,” as in continuous integration, continuous testing, and regular packaging.

Regardless of one’s specific interpretation of the meaning of DevOps, the root value is cross-functional I.T. skills teamed to focus on solutions collectively. The upside is that it breaks I.T. silos in the software lifecycle. So just as I.T. silos in the Enterprise are counter-productive (who among those reading this has not experienced the joy of submitting a ticket to a Service Desk then watching it endlessly bounce between I.T. teams?), DevOps is a value-add to software and platform. DevOps in the Public Cloud bridges communications problems, allows cross-functional IT skills to be fully leveraged, and allows teams to reduce size, while remaining flexible to meet evolving business needs.

8C L O U D G U A R D R A I L S

DevOps is a culture change from more legacy practices. The recommendation is to embrace it, but it likely requires updating staff skills (e.g., training) and will also likely take some time to implement fully.

Infrastructure as Code (IaC)Think programmatically to solve complex and critical infrastructure operations.

The Public Cloud offers many compelling features: scale, elasticity, proximity, and PaaS, among others. However, one significant feature and a fundamental component of DevOps is Infrastructure as Code (IaC).

In short, IaC is the process and technologies of provisioning and managing computer data centers, networks, and services programmatically. This process is in contrast to deploying physical hardware, power, cooling, cabling, etc., and manually configuring services.

Two IaC orchestration tooling examples are CloudFormation (AWS) and Terraform (HashiCorp, Inc.).; the former is specific to AWS, while the latter is multi-Public Cloud.

Technologies such as Saltstack, Ansible, Puppet, and Chef—known as “configuration management” tools—have been used in legacy data centers to automate the deployment of Operating Systems, applications, databases, and more. IaC technologies take the paradigm further by providing the means to “code” entire virtual data centers.

When using IaC orchestration in concert with configuration management tools, we get programmatic automation supporting entire Public Cloud solution stacks. Further, the same configuration management tooling approach used in Public Cloud can also be leveraged in more legacy infrastructure technology environments, providing consistency in deployments and administration spanning on-premises, co-location, Private Cloud, and Public Cloud environments.

The upside is that computing environments are created and managed using software engineering principles and rigor, and are maintained via design, code versioning, and change management processes akin to those used by software developers. The result is a well-defined and controlled services platforms with the ability to roll in and back-out changes “on the fly.” Moreover, security updates are defined, tracked, and consistently applied where needed.

When using IaC orchestration in concert with configuration management tools, we get programmatic automation supporting entire Public Cloud solution stacks.

9C L O U D G U A R D R A I L S

A Little Help Goes a Long WayYou know you need help, but what help do you really need?

Information Security is a mix of focuses to keep your information secure (see what I did there?). To this end, there is automation geared toward consistently administering platforms and applying policies. There is also the need for auditing and testing, being one’s “Checks and Balances” (see below for more).

A single account and network space (a Virtual Private Cloud or VPC in AWS terms) is simple, and you may feel that supporting tooling may not be required. That perspective may or may not be right, but again think about getting all the help you can. Best practices for Public Cloud is to split services by group or function across accounts – the “multi-account model” – which allows for variances in governance and change management; enables service levels to be dedicated to such groups; and “limits the blast radius” should something go [really] wrong. Not to mention that two, three, 10, or perhaps 100+ Public Cloud accounts, become a federation challenge and an administrative risk and burden.

SECTION 3

Just because you and your team are confident in your Cloud’s security and viability, doesn’t mean that others can’t find areas to improve.

10C L O U D G U A R D R A I L S

Policy/Administration Through Centralized ManagementTo help in this area, AWS offers Organizations and Control Tower APIs (other Public Clouds are keeping pace with such features). While compelling and certainly viable, be mindful that if you use an AWS tool, it will likely serve only AWS environments. In today’s modern Public Cloud era, it is a best practice to leverage multiple Public Cloud providers (for diversity and leverage the strengths of each to facilitate workflows). It is certainly desirable to avoid multiple administration tools and paradigm in favor of a “single pane of glass” administrative perspective.

With this in mind, a security/guardrails platform like Turbot (Turbot HQ, Inc.) supports multiple Public Cloud vendors with a single approach to platform security and administration. There are certainly competitors to Turbot, and this is not intended to be advertising for that offering, but be aware that many competing technologies are agent-based or abstract the Public Cloud platform from the administrators (tooling should meet needs without being intrusive or adding overhead).

Checks and BalancesDon’t become complacent—you’ve established a Public Cloud environment with the needed services and supports to be secure and valuable to the business, but you still need to “trust but verify” your implementations.

For all Public Cloud platforms, it is advisable to set up some form of monitoring with corresponding alerting/alarming. Monitoring most certainly needs to include all perimeter (Internet-facing) and ingress points, and ideally would include all services in the Public Cloud. Most often, this is in the form of quasi-real-time log collections feeding into analytics engines that include those from Public Cloud services, as well as those further up the application stacks. Such log collection is likely to include on-premise and other legacy computing environments. Splunk (Splunk Inc.) has become a de-facto standard for this, but here too are many viable alternatives.

Beyond on-going monitoring, it is advisable to perform periodic third-party Information Security and Platform reviews, including Penetration Testing (Pen Testing) to find vulnerabilities in your network and monitor your team’s ability to detect attacks. Additionally, one last facet of getting help is engaging Information Security experts to independently review and asses your Public Cloud implementations (best if also including on-premises and other legacy compute environments for that holistic perspective). Just because you and your team are confident in your Cloud’s security and viability doesn’t mean that others can’t find areas to improve.

11C L O U D G U A R D R A I L S

How often should these checks and balances be exercised? As noted, log collection and analyses should be continual. As for audits and related testing, some Enterprises appear to be content annually, while others are more aggressive in their schedules. The direction taken becomes a business decision because these types of engagements cost money and time. They are also disruptive to business initiatives as staff that would typically be focusing on business objectives must devote energies to supporting such testing.

Likely, it’s best to use some common sense when trying to set the frequency for engaging for third-party security reviews. If your environment is relatively static, perhaps annual testing is sufficient, but if your environment is more dynamic or has higher risks via the number of Internet-facing services, you’ll likely want to consider more frequent audits.

Are you in need of Cloud computing support?For more than three decades, RCH Solutions has provided specialty computing advisory and managed services exclusively within the Life Sciences. Find out how RCH can support your next Cloud initiative.

rchsolutions.com | discover@rchsolutions.com

Objective Advice, Experienced Execution

The final piece of this critical puzzle is the invaluable perspective an outside computing partner can provide for your Public Cloud strategy at large, whether through consultation or support at the beginning, middle, or end of a project. After all—and usually by no specific fault—it can be challenging to see the forest for the trees when you’re standing under a hundred-foot oak. The opinion of an outside perspective can often challenge even the strongest of teams to find new or more appropriate solutions to common or plaguing issues, and bring a beneficial dynamic to a Cloud team.