Cloud Security For Dummies
Description
Cloud technology has changed the way we approach technology. It's also given rise to a new set of security challenges caused by bad actors who seek to exploit vulnerabilities in a digital infrastructure. You can put the kibosh on these hackers and their dirty deeds by hardening the walls that protect your data.
Using the practical techniques discussed in Cloud Security For Dummies, you'll mitigate the risk of a data breach by building security into your network from the bottom-up. Learn how to set your security policies to balance ease-of-use and data protection and work with tools provided by vendors trusted around the world.
This book offers step-by-step demonstrations of how to:
* Establish effective security protocols for your cloud application, network, and infrastructure
* Manage and use the security tools provided by different cloud vendors
* Deliver security audits that reveal hidden flaws in your security setup and ensure compliance with regulatory frameworks
As firms around the world continue to expand their use of cloud technology, the cloud is becoming a bigger and bigger part of our lives. You can help safeguard this critical component of modern IT architecture with the straightforward strategies and hands-on techniques discussed in this book.
More details
Other editions
Additional editions
Person
Content
Chapter 1
Clouds Aren't Bulletproof
IN THIS CHAPTER
Taking charge of cloud security
Building a security team
Coming up with a risk management plan
Taking on security responsibilities
Letting cloud service providers handle some of the security
All the great innovators have been known to "have their head in the clouds." Now it's your turn. Cloud computing is one of the greatest innovations of modern computing since the Internet, but with all its many benefits come certain responsibilities. One vital responsibility is the management of security. You can think of clouds as Infrastructure Elsewhere, but the security of all infrastructure must be managed. In this chapter, I spell out the basics of getting to know your business so that you can best create a security plan, which is the first step toward optimal application and data security when using clouds.
For the most part, whenever I mention clouds in later chapters, I'm talking about public clouds, like AWS and Google Cloud. I reserve Chapter 9 for a more detailed discussion of private and hybrid clouds.
A word to the wise: When the responsibility for cloud security falls in your lap, don't panic. You'll soon find out that, with the right plan and the right tools, the task can be easily managed. To get started, you have to get to know your business. You may think you know it, but in order to provide truly successful security, you have to know it in detail, beyond just knowing the name of the person manning the front desk.
Knowing Your Business
It's great to know exactly what your business sells, whether it's widgets or services, but when it comes to cybersecurity, you need to know your business a bit more intimately. This new insight into how your business runs not only allows you to create a rock-solid security plan but also may help you innovate by better understanding how things get done. One of the first steps is knowing what you want to protect.
Discovering the company jewels
It's time to gather your first thoughts about cloud security into an actionable strategy, by understanding which assets you're trying to protect. This becomes the most important part of your plan. Depending on the size of your company, the strategies will start to differ. If you're thinking that cloud security doesn't differ much from everyday cybersecurity, you're absolutely correct. Getting cloud security right means you have a plan for all your cyberassets - wherever they live and operate.
Create an inventory of all your assets. Later in this chapter, I offer some suggestions for creating the right team. It's best to rely on them when creating an inventory of assets rather than try to noodle it out yourself.
Initiating your plan
Small companies can start their plan in a spreadsheet. You could probably get away with using a simple yellow legal pad, but then it's not so easy to share with others, and that is the part of the plan that comes next. Create a spreadsheet or database if you're more comfortable with it and start to list all applications used by your company. (It's easier said than done!). Many departments use applications that are hidden from the IT department. These siloes are towers of applications and data that are cut off from the other parts of the company - for example, accounting applications that are in use only by Accounting or sales tracking applications used only by Sales. This single exercise can be an eye-opener. You may look at the list and think, "Who is watching all this stuff?" That's why you start here.
All your applications are creating and using data. Each application on your list should also include information about the kinds of data it creates or uses.
Automating the discovery process
Larger organizations might use automated discovery applications that can help you create a basic list of applications, networks, and data. This is a particularly important first step when migrating to the cloud. For example, Amazon Web Services (AWS, for short) has an application called the AWS Application Discovery Service. (More about that service in the next sections.)
AWS Discovery Service
The AWS Discovery Service collects and documents information about the applications in use within your company and then stores that information in an AWS Migration Hub. This vital data can then be exported into Excel or certain AWS analysis tools. This is the data that underlies your ultimate cloud security plan!
AWS also has APIs (application programming interfaces) that allow you to store performance data about each of these applications. (Save room for storing the risk level information I talk about later in this chapter.)
There are two ways to gather information using the AWS Discovery Service:
- Agentless: This system collects data by gathering it from your VMWare application. If you have not deployed virtual machines at this point in your migration to the cloud, this system won't be useful. If you choose AWS as your cloud service provider, you'll find that AWS and VMWare are intricately interconnected.
- Agent-based: Deploy this application on each of your servers, both physical and virtual. The system then collects a variety of information, including the number of applications currently running on the server, the network connections, the performance metrics, as well as a listing other processes currently running.
Google Cloud Discovery Service
This particular discovery service is built into the Google Cloud. If you've already gotten started using the Google Cloud for your applications, you can make use of instance metadata, which is great for obtaining information on elements such as an application's IP address, the machine type, and other network information.
The project metadata collected by the Google Cloud Discovery Service tracks the same kind of information but includes applications that may still be running in your (physical) data center. When you're ready to tackle collecting instance and project metadata, check out the following link to Google documentation on storing and retrieving this kind of information:
https://cloud.google.com/compute/docs/metadata/overview
Knowing Your SLA Agreements with Service Providers
A service level agreement, also known as an SLA, spells out the performance and reliability levels promised to you by your cloud service provider. Though performance isn't technically part of cloud security, it's part of the overall availability of your applications and data. Your company's IT department likely has SLA agreements in place with the departments it serves. These SLA agreements depend on the cloud service providers doing their part, and they give you an idea of what they promise. For example, you can't promise 99.99 percent uptime if the cloud service provider offers only 99.5 percent. Some SLA agreements might also include references to the security they provide.
One main benefit of using the cloud is that some of the security responsibility for your applications is handled by the cloud service provider. This normally includes physical security and some, but not all, antimalware security. They may additionally offer security services for hire.
Here are links to the many SLA agreements offered by some of the top clouds. Though this list is by no means complete, it gives you an idea of what's being offered and what you might expect from the cloud service provider you select or have selected:
- Amazon:
https://aws.amazon.com/legal/service-level-agreements - Google:
https://cloud.google.com/terms/sla - Oracle:
www.oracle.com/cloud/sla
These service level agreements cover issues such as guaranteed uptime, disk operation efficiency, domain name system (DNS) integrity, email delivery, and more. Most of these are guaranteed at levels approaching 100 percent. Because nothing is perfect, they usually guarantee 99.99 percent or 99.95 percent for the unforeseen failures that can and do happen, but I wouldn't lose sleep over it. Statistically, you're safe with these services.
Where is the security?
One promise that's hard to track down in a cloud service provider's SLA is one concerning security. Security isn't guaranteed - just implied. Cloud service providers protect your data and applications to the limit of their ability, including issues such as physical security and some degree of malware detection by a 24/7 network operations center.
Because security is a shared responsibility, you often find that, in discussions about their security, cloud service providers talk about how they can help you create a secure cloud experience. Many of them have tools for these tasks:
- Encrypting data
- Monitoring for malware attack
- Remediating catastrophic failure
Some of the applications that perform these tasks are third-party products and services that interoperate with the cloud service provider. You generally find the partner companies listed on the...
