Designing Secure Networks in the Clouds
We can help in making sure the best practises for Cloud Security are followed and any deviations are detected and brought to every one's notice.
When developing a cloud security architecture several critical elements should be included:
- Security at Each Layer
- Centralised Management of Components
- Redundant & Resilient Design
- Elasticity & Scalability
- Appropriate Storage for Deployments
- Alerts & Notifications
- Centralization, Standardisation, & Automation
Some threats and issues may also be more specific to the type of cloud service:
Cloud services are affected by the most common types of concerns and threats, including data breaches, malware injections, regulatory non-compliance, insider threats, advanced persistent threats (APTs), credential stuffing attacks, insecure application programming interfaces (APIs), zero-day attacks, account hijacking through stolen or compromised credentials, phishing, and service disruptions due to denial-of-service attacks or misconfigurations. If a breach occurs, liability for the breach is based on the shared responsibility model.
IaaS Cloud Security Threats
- Availability disruption through denial-of-service attacks
- Injection flaws
- Broken authentication
- Sensitive data exposure
- XML external entities
- Broken access control
- Security misconfigurations
- Cross-site scripting (XSS)
- Using components with known vulnerabilities
- Insufficient logging and monitoring
- Data leakage (through inadequate ACL)
- Privilege escalation through misconfiguration
- DoS attack via API
- Weak privileged key protection
- Virtual machine (VM) weaknesses
- Insider data theft
PaaS Cloud Security Threats
- Privilege escalation via API
- Authorization weaknesses in platform services
- Run-time engine vulnerabilities
- Availability disruption through denial-of-service attacks
- Injection flaws
- Broken authentication
- Sensitive data exposure
- XML external entities
- Broken access control
- Security misconfigurations
- Cross-site scripting (XSS)
- Insecure deserialization
- Using components with known vulnerabilities
- Insufficient logging and monitoring
- Data leakage (through inadequate ACL)
- Privilege escalation through misconfiguration
- DoS attack via API
- Privilege escalation via API
- Weak privileged key protection
- Virtual machine (VM) weaknesses
- Insider data theft
SaaS Cloud Security Threats
- Weak or immature identity and access management
- Weak cloud security standards
- Zero-day vulnerabilities
- Shadow IT/unsanctioned cloud applications/software
- Service disruption through denial-of-service attacks
- Phishing
- Credential stuffing attacks
- Weak compliance and auditing oversight
- Stolen or compromised credentials
- Weak vulnerability monitoring
As you move into the process of developing a robust cloud security architecture, it is important to spend some time understanding the shared responsibility model , the various cloud security best practises, and how best to approach cloud security within the context of your business’ needs, obligations, and risks. Depending on the types of cloud services your organisation uses, cloud security architectures can be complex. It is important to not underestimate the time and skills necessary to develop a robust and effective security architecture.
Provisioning Infra as Programming Constructs
Infrastructure-as-code promises to provide consistent, reliable, repeatable, and automated infrastructure provisioning and management. Our consultants can help using the tools and frameworks associated with Infrastructure-as-code construct to streamline and simplify your deployment processes. Few of the AWS tools & products that can help are -
In CloudFormation you describe the AWS resources you want to provision through declarative configuration statements, in either JSON or YAML format. YAML format tends to be more common these days since it is generally easier to read for humans.
When CloudFormation provides resources, it works with a unit of deployment called a stack. CloudFormation tracks the state of all resources in a stack, so if you do a change and ask CloudFormation to apply the change, only the resources that need to change will be changed. You can apply changes directly, or via Change Sets, for which you can review the expected changes before they are applied.
Terraform can provision resources not only in AWS but other providers as well. It is not restricted to cloud infrastructure providers only either. Instead, you can provision resources from many providers.
You use declarative configuration descriptions with Terraform, using HCL (Hashicorp Configuration Language), although it is technically possible to represent resources as JSON as well.
If your use cases for cloud infrastructure are restricted to publicly available web applications and APIs, then AWS AppRunner may be a suitable choice.
This relatively new service from AWS is quite simple in terms of infrastructure management but supports only some specific use cases.
Similar to AWS AppRunner, AWS Copilot handles web application and microservice API use cases. AWS Copilot handles more use cases, and a bit more complex infrastructure solutions and staging scenarios.
Pulumi launched in 2018. It is an open-source toolset that covers a multitude of providers, cloud infrastructure, and others as well. Pulumi has a bridge feature that lets it use Terraform providers. A key difference here though is that it uses regular programming languages to describe the infrastructure, not a (custom) configuration language/format.
In Pulumi, infrastructure is organised in projects. A project in turn contains a program, which is the description of the infrastructure. A project may also consist of one or more stacks, which are the deployable units of the program.
A program in itself works with resources, which describe the infrastructure. These can be the provider’s resources, as well as higher-level resources composed of multiple lower-level resources. Inputs and outputs between these resources describe the dependencies involved.
Similar to Pulumi (and AWS CDK later in the list), it supports many programming languages, including Typescript, Python, C#, Go (soon), and Java. Any module or provider supported in Terraform is available to use through CDKTF.
CDKTF has a concept of an App. The app contains the program code that describes the infrastructure. The code may create one or more stacks, which are units of deployment. Constructs represent infrastructure resources. These maps directly to the provider’s resources, or more higher-level components. A process called synthesising executes the code to produce Terraform JSON resource descriptions, which is then used to provision resources. You can use the CDKTF-specific tooling to deploy these stacks or the regular Terraform tooling.
AWS CDK shares many properties of CDKTF – it supports many programming languages, including Typescript, Python, C#, Go (soon), and Java. It also shared the concepts of an App, the program code that describes the infrastructure. The code may create one or more stacks, which are units of deployment. Constructs represent infrastructure resources. These maps directly to the provider’s resources, or more higher-level components. A process called synthesising executes the code to produce Cloudformation JSON resource descriptions, which is then used to provision resources.
The AWS CDK-specific tooling is significantly better than what is provided for lain CloudFormation, and also provides additional assets handling in addition to the plain CloudFormation, such as deploying code and data.
AWS CDK is focused on AWS naturally and does not support other providers outside of AWS. Technically it is possible to build custom components outside of AWS.
A key benefit with AWS CDK is its many higher-level components on top of what is provided by CloudFormation. A general principle is to provide sane best practice defaults and allow customizations if needed.
Access permissions and network access have higher-level mechanisms in place. Thus you do not need to understand and know precisely which permissions or security rules to set, the AWS CDK will figure that out for you based on the guidance you have provided. If you connect different resources, it will often automatically set the permissions needed for these to communicate with each other.
AWS starts to provide more examples using AWS CDK also, and not only CloudFormation. It is a key toolset for AWS moving forward.
Connecting On-premises And Cloud Environments Securely
When organisations migrate their applications, workloads, and data into public cloud environments, IT administrators must increasingly manage and secure their resources across multiple virtual clouds and on-premises corporate networks. And as cloud resources grow across multi- and hybrid-cloud environments, protecting access, applications, and data for workload deployments becomes an increasingly complex task.
Traditionally, Infrastructure as a Service (IaaS) providers such as AWS are responsible for the security and availability of their own infrastructure as part of the cloud “shared security model.” However, organisations are ultimately responsible for both the security of their own applications, workloads, and data in the public cloud and the protection of on-premises and private cloud resources.
We offer end-to-end cloud resource visibility, management, and protection for AWS while at the same time enabling organisations to manage their resource access across multi-cloud environments for security and compliance risk management.
Minimal Operational Overhead
In today’s landscape, achieving operational excellence can be difficult, but not impossible. With operations often viewed as distinct from the rest of the business, it sometimes isn’t integrated into the flow like it is for other departments.
Operational excellence design principles
Perform operations as code
The beauty of the cloud is that you can apply the same scripting skills you use to code applications to your entire environment, including operations. This means, you can reduce the need for human intervention by scripting code that will automate operations and trigger appropriate responses to any events or incidents.
Make frequent, small, reversible changes
When multiple, large changes are made at once, it becomes exceedingly difficult to troubleshoot a problem when things don’t work in production. When designing your workloads, allow for small and frequent deployments that are easily reversible to make the process of identifying the source of the problem quick and easy when something isn’t running as intended in production.
Refine operations procedures frequently
There is always room for improvement. Continually analysing and poking holes in your processes and procedures helps you to constantly increase the efficiency of how you serve your customer needs.
Anticipate failure
It is always better to expect failure, rather than assuming that what you’ve created is flawless. If you don’t anticipate errors, how can you catch them before deployment. This is effectively the process of threat modelling and risk assessment.
Learn from all operational failures
The point of going back and analysing a failure is to learn from it. It is important to set up structures and processes that enable the sharing of learnings across teams and the business.
We help you to align with your Operations goals using AWS Solutions & Tools
- Use Managed Services - No worrying about managing servers, availability, durability etc
- Go Serverless - Prefer Lamda to EC2
- Automate with CloudFormation - Use Infrastructure as Code
- Implement CI/CD pipelines to find problems early - Use CodePipeline, CodeBuild, CodeDeploy
- Perform small, reversible changes
- Prepare for failure - Game Days, Disaster Recovery Exercises
- Operate: Gather Data and Metrics - Cloudwatch, Config, Config Rules, VPC flow logs & XRay
- Evolve: Get Intelligence - Use AWS ElasticSearch to analyse your logs
