In the pre-cloud era, to permanently delete data, the sectors on the physical disk must be overwritten multiple times with zeros and ones to make sure the data is unrecoverable. if the device will not be re-used, it must be degaussed. The Department of Defense standard, DoD 5220.22-M, goes so far as destroying the physical disk through melting, crushing, incineration or shredding to completely get rid of the data.

But these techniques do not work for data in the cloud. First, cloud customers probably will not have access to the provider’s data centers to access the physical disks. Second, cloud customers do not know where they are written, i.e. which specific sectors of the disk, or which physical disks for that matter. In addition, drives may reside on different arrays, located in multiple availability zones, or data might even be replicated in different regions.

The only way to permanently erase data in the cloud is via crypto-shredding. It works by deleting the encryption keys used to encrypt the data. Once the encryption keys are gone, the data cannot be recovered. So it is imperative that even before putting data in the cloud, they should be encrypted. Unencrypted data in the cloud will be impossible to permanently delete. As a cloud customer, it is also important that you own and manage the encryption keys and not the cloud provider.

Two of the most common security issues in AWS are platform misconfigurations and credential mismanagement.  Although AWS offers many security features, if they are not used or not configured correctly, your applications and data will be vulnerable .  However, these common security issues can be easily mitigated using the following best practices:

1.  Use VPCs (virtual private clouds). Amazon Virtual Private Cloud (Amazon VPC) enables you to launch AWS resources into a virtual network that you’ve defined. This virtual network closely resembles a traditional network that you’d operate in your own data center. It is logically isolated from other virtual networks in the AWS Cloud. You can launch your AWS resources, such as Amazon EC2 instances, into your VPC.  You can apply security groups and access control lists to the VPC to secure it.

2. Limit administrative access with AWS Security Groups. A security group acts as a virtual firewall for your instance to control inbound and outbound traffic. When you launch an instance in a VPC, you can assign up to five security groups to the instance. For each security group, you add rules that control the inbound traffic to instances, and a separate set of rules that control the outbound traffic.  Security groups helps block attackers who may try to probe your AWS environment.

3. Lock down your root, domain, and administrator-level account credentials. For day-to-day operations, use your own account and only use these privileged accounts when absolutely necessary.  Don’t share passwords and only a handful of administrators should have possession of the passwords.

4.  Use IAM Roles. An IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session. IAM roles can be used to define permission levels for different resources and applications that run on EC2 instances. When you launch an EC2 instance, you can assign an IAM role to it, eliminating the need for your applications to use AWS credentials to make API requests. 

5. Enable Multi Factor Authentication (MFA). MFA is a simple best practice that adds an extra layer of protection on top of your user name and password. With MFA enabled, when a user signs in to an AWS website, they will be prompted for their user name and password (the first factor—what they know), as well as for an authentication response from their AWS MFA device (the second factor—what they have). Taken together, these multiple factors provide increased security for your AWS account settings and resources.

6. Mitigate distribute denial of service (DDoS) attacks by using elastic load balancing, auto scaling, Amazon Clouldfront, AWS WAF, or AWS Shield. AWS provides flexible infrastructure and services that help customers implement strong DDoS mitigations and create highly available application architectures.

7. Monitor your environment by using AWS tools including CloudTrail, CloudWatch and VPC Flow Logs.  They provide information about how data flows in and out of your AWS environment. They also provide data that you can mine and analyze to check intrusions, security breaches, and data leaks. You can also integrate these tools with third party applications that can perform thorough log analysis and event correlation.

Source: https://docs.aws.amazon.com/

To create a solid security for your servers, data, and applications hosted in the cloud, you must adhere to the following security guiding principles:

Perimeter Security

The first line of defense against attacks is perimeter security.  Creating private networks to restrict visibility into computing environment is one of them.   Micro-segmentation which  isolates applications and data with a hardened configuration is another one. Creating  a strong abstraction layer from hardware and virtualization environment will also strengthen perimeter security.  

Continuous Encryption

There shouldn’t be any more reason why data traversing the network (public or private) and data stored on storage arrays shouldn’t be encrypted.  Even the popular Google Chrome browser started to flag unencrypted websites to alert users.  Leverage cheap computing power, secure key management, and the Public Key Infrastructure to achieve data-in-transit and data-at-rest encryption. 

Effective Incident Response

Attacks to your servers, data, and applications in the cloud will definitely occur.  It’s just a question of “when” will it happen.  An effective incident response program – using automated and manual response – ready to be invoked once an attack occurs will lessen the pain of the breach.

Continuous Monitoring

Continuous and robust monitoring of your data, applications, and security tools and on-time alerting when security breach happens is a must.  In addition, easy integration of third party monitoring capabilities will also help in achieving sound monitoring system.

Resilient Operations

The infrastructure should be capable of withstanding attack.  For instance, you should maintain data and applications availability by mitigating DDoS attacks. The applications should continually function in the presence of ongoing attack.  In addition, there should be minimal degradation of performance as a result of environmental failures. Employing high availability, redundancy, and disaster recovery strategy will help achieve resilient operations.

Highly Granular Access Control

Organizations need to make sure that their employees and customers can access the resources and data they need, at the right time, from wherever they are. Conversely they need to make sure that bad actors are denied access as well.  They should have a strong cryptographic Identity and Access Management (AIM).  They should leverage managed Public Key Infrastructure service to authenticate users, restrict access to confidential information and verify the ownership of sensitive documents.

Secure Applications Development

Integrate security automation into DevOps practices (or DevSecOps), ensuring security is baked in, not bolted on.

Governance, Risk Management, Compliance

Finally, a great cloud security program should be properly governed, for instance, by having visibility of configurations. Risks should be managed by readily identifying gaps or other weakness.  Lastly, your security program should have broad regulatory and compliance certifications.

One of the big differences between cloud security and on-prem security is that the former is built from the ground up while the latter is bolted in the process. AWS for instance had made their infrastructure secure ever since they first built it. They realized early on that companies will not be putting their data in the cloud if it’s not inherently secure.

However, security is still a shared responsibility between the cloud provider and the consumer. By now, everybody should be aware of the AWS Shared Responsibility Model. Companies who are used to the traditional security model will find that cloud security entails a different mindset. In the cloud, the focus shifts from network, operating systems, and perimeter security to security governance, access control, and secure development. Since the underlying infrastructure of the cloud is secured by the provider, companies utilizing it can now focus on the true information security – the ones that really matters to the company, such as data, users, and workflow security.

Security governance is important in the cloud. Security folks should spend more time planning and less fire fighting. They should be crafting and implementing policies that truly secure the company’s assets – such as data-centric security policies and secure software development. There should be a solid access control. For example, users are only granted access if they really need it.

There are a couple of challenges with cloud security. First is the obvious disconnect between shared security model and traditional security model. Companies used to on-prem security will still want to spend resources on perimeter security. Second is compliance. For instance, how can traditional auditors understand how to audit new technologies in the cloud like Lambda, where there is no server to verify?

Companies using the cloud should realize that security is still their responsibility but they should focus more on data and application security.

I recently attended the ISC2 Security Congress held on Oct 8 to 10, 2018 at the Marriott Hotel in New Orleans, Louisiana.  Based on the keynotes, workshops, and sessions at the conference, these are the challenges and opportunities facing cloud security:

1. Container and serverless (e.g. AWS Lambda) security.  For instance, how will you ensure isolation of various applications?
2. Internet of Things (IOT) and endpoint security.  As more and more sensors, smart appliances and devices with powerful CPUs and bigger memories are connected to the cloud, more computation will happen on the edge, thus increasing security risks.
3. Machine learning and artificial intelligence (AI).  How can AI help guard against cyber-attacks, predicts impending security breach, or improve investigation or forensics?
4. Blockchain technology. Blockchain will be transforming how audits will be performed in the future.
5. Quantum computing if and when it comes into fruition will break cryptography.  Cryptography is the reason why commerce happens on the Internet.  New encryption algorithm is needed when quantum computing becomes a reality.
6. How will the implementation of GPDR (General Data Protection Regulation) in the European Union affects data sovereignty (“a concept that information which is stored in digital form is subject to the laws of the country in which it is located”), data privacy, and alignment of privacy and security?
7. DevSecOps (having a mindset about application and infrastructure security from the start) will continue to gain momentum.

We are likely to be seeing continuing innovations in these areas within the next few years.