ADD SOME TEXT THROUGH CUSTOMIZER

Foundations of Architecting Cloud Security

As we all know, this topic is one of the most critical and large topics, and there is no way a single blog or even a single book can cover it completely. Nevertheless, this blog aims to provide a simplified summarized guide, buy putting together the key security principles and approaches that untimely can help to build the foundation of a secure cloud solution.

Cloud Security without any doubt is a paramount concern for any cloud hosted solution. Typically, when organizations consider a public cloud environment, today there might be a level of executives or stakeholder unease when you a newer technology or approach, as some may feel uncomfortable with the idea of having corporate and sensitive data not under their direct physical control of internal IT staff and hardware, housed in proprietary data centers.

However, this vary based on the organization’s business functions nature and the associated policies and any regulatory or contractual requirements, technically different applications and systems will have their own specific security requirements and controls.

Within a cloud environment, this becomes more important and critical, simply because the nature of cloud as a multi-tenants environment, in which the the cloud provider needs to ensure each customer that their controls are being met, and done so in a way that the cloud provider can support, with varying requirements.

This is take us to the first step when looking at architecting security in such environment which is: who’s responsible of what? (this is with regard to, drawing a clear demarcation line, between the cloud provider responsibility and the cloud services consumer or customer)

In General, public cloud providers use the ‘shared responsibility model’, the below chart from aws.com illustrates the divided security responsibilities “demarcation line’ between the cloud provider and the customer.

Technically, this “demarcation line” of the security responsibilities vary based on the used cloud service delivery model. Typically, the more you go up in the cloud delivery model (IaaS > PaaS > SaaS) the more the security responsibilities are offloaded to the cloud provider.

In a cloud or traditional/On-Prem data center environment, identifying what need to be secured and then deciding how to secure it, is a lengthy process and there is no single best answer because these decisions, depend on the organization nature, organization security standards, industry, compliances, systems and applications in use, data criticality, etc.

For the purpose of this blog, let’s looks the below, Cloud Computing Cybersecurity Threats, along with the mitigation solution(s), regardless which one is the most or least critical.

These are only a few of many possible Cybersecurity Threats in a cloud environment. Like with any security design, to architect security in a cloud environment, In general, there are many specific security practices. Still, they flow from a small set of well-accepted principles. Therefore, by having a good understanding of the fundamental approaches, it puts you in the best position to make your architectural decision and approach of certain practices where needed in your cloud environment.

Security Is Holistic

When design any security solution, it is key to remember that “security is a process, not a product”, that’s why the basic proven approach is to cover all the layers. Starting from the physical all the way to the application as well as educating people, adding process etc.. In fact, it is critical to distinguish that even if your system is physically and technologically secure, you still need to create a certain set of policies and procedures for all the staff who has access to the system to ensure overall security.

in addition, the design of the security solutions of each layer or component must not be design in isolation of the other ones, because in the end these layers and systems need to work together.  This is what is referred to design in isolation, where different component of a system are treated in isolation and this this potentially may lead to interoperability issues.

That being said, practically, cloud architects along with security professionals should spend some period of time thinking and analyzing the potential types of information and cybersecurity threats that the targeted solution and business may faces, and how to link it to “Risk Management” to be able to prioritize security risks among other business risks.

Furthermore, considering one or more security features in the solution, does not ensure end to end security. For instance, in a simple client-server communication a client might send a password to the server, and you do not want a man-in-the-middle to be able to eavesdrop and see the password during transmission. Typically you could encrypt such traffic in transit using client side encryption, to encrypt the password at the client before sending it to the server. Although here the password is encrypted and secure in transit, this does not grantee that the client-server solution is completely secure, since there are other things that could go wrong. In particular, encrypting the client’s password does not ensure protection against weak passwords. Similarly, protecting communication with a DB system does not protect the solution or system from other potential cybersecurity threats e.g. SQL injection, DoS attacks, etc. even though the client communicate with the DB server over an encrypted connection using SSL.

As highlighted above, Security is a process, not a product, that’s thinking holistically about security is key, to design a secure cloud solution (as well as, any other system).

Designing-In Security

When cloud architect and security professionals design security into a cloud solution, they should keep security in mind while building the cloud solution, starting with its initial requirements and design phases. Otherwise, it is not feasible or advisable to start design the cloud solution such as how the VMs in a VPC will be communicating, which DB will be used and how to connect etc., and then at a later stage the team will worry about how to make it secure. Practically, this approach in traditional or cloud based solutions, has shown that it is very hard to add on security later, and may lead to some design alterations to accommodate the security later.

In many situations, you may notice that, customers mainly pay for functionality and performance for cloud solutions, and not necessarily security or privacy. Nevertheless, customers still expect security and privacy as part of the cloud solution, even if they do not explicitly pay for it. On the other hand, if the cloud project is new or small, you may not initially have much to protect, and if you don’t consider security properly, once there is something to protect, redesigning the entire cloud project from scratch for security is usually not an option.

Therefore, best approach is to design it with security in mind, and incorporate necessary security aspects into your cloud solution starting from the beginning, and will provide the flexible to incrementally add and integrate more security functions and features as the project grow.

Design for Failure aka Fail-Safe Stance

This design approach, involves designing a solution or a system in such a way that even if one or more of its components fail, the solution or system should still be capable to provide an acceptable level of security.

A simple example, how a cloud firewall solution is designed to keep malicious traffic out following a failure event?

Will it  deny access by default and not let any traffic in (this for sure will be inconvenient for users, while its ensure protection during the failure event) on the other hand, should you consider redundancy, or invoking a DR failover to another VPC or On-Prem DC in such failure scenario? There are multiple possible options, the goal is to design the solution to be capable to operate following a failure event, without compromising security recruitments.

Otherwise, if, the cloud firewall design when it fails it should let all traffic through, then attackers could simply figure out how to induce the firewall to fail e.g. conducting a DoS attack, and then would be able to send malicious traffic in.

Defense-in-Depth

The key point of defense-in-depth is to not to count on any one defense to achieve security at any zone or area. Instead, multiple layers and mechanisms should be used to help you achieve more security than just one layer or mechanism. Simple example here that you can think of is how secure buildings are protected, there is an external gate with security guards, as well as CCTV cameras ( these like the edge firewall and IPS). Then there is cameras in the car park ( like IPS/IDS in transit zone). Then when you try to access the building itself, there is another security check with CCTV cameras as well, (this is like the second layer of Firewalls, WAF and IPS for a specific zone). After you are inside the building, if you need to access any room or office you have to have access card to let you in, this like host level security host Firewall antivirus, IPS etc.) . these mechanism and layers of security should be design to be caoble to prevent an attack before it take place, and detect any attack that was not prevented. Practically, it is not always possible to prevent attacks altogether, Therefore, it is important to consider in the solution design mechanisms that help to manage or contain attacks while they are in progress. Last but not least, After an attack takes place, you want to be the systems and applications to able to recover from the attack, to whatever extent possible, sometimes cloud be invoking a DR failover, to maintain business continuity.

For instance the below figure from Cisco illustrates how organizations (cloud or On-Prem) can address the full attack lifecycle or continuum.

https://www.cisco.com/c/en/us/products/collateral/security/whitepaper_c11-733368.html

https://www.ironshare.co.uk/technical/ciscos-attack-continuum/

Also, The NIST cybersecurity Framework consists of standards, guidelines, and best practices to manage cybersecurity-related risk.

https://www.nist.gov/cyberframework

Securing the Weakest Link

A system is only as strong as its weakest link. The weakest link here refer to an element of a system that is the most vulnerable, susceptible, or easiest to attack. This could be a weak password, updated software/OS or even could refer to people as well as lack of standardizations and experienced cloud security professionals in some compnies.

According to Cisco security report 2018 “As applications, data, and identities move to the cloud, security teams must manage the risk involved with losing control of the traditional network perimeter. Attackers are taking advantage of the fact that security teams are having difficulty defending evolving and expanding cloud and IoT environments. One reason is the lack of clarity around who exactly is responsible for protecting those environments. To meet this challenge, enterprises may need to apply a combination of best practices, advanced security technologies like machine learning, and even some experimental methodologies, depending on the services they use for their business and how threats in this space evolve”

Not to mention, protecting against people (specifically internal users) in terms of what they can upload and download etc. to the environment sometimes is underestimated.

According to Cisco security report 2018, “Insider threats: Taking advantage of the cloud Machine-learning algorithms hold the promise of providing greater visibility into the cloud and user behavior. If defenders can start predicting user behavior in terms of downloads, they can save the time it might take to investigate legitimate behavior. They can also step in to stop a potential attack or data-exfiltration incident before it happens.”

Secure by Default

When architecting a cloud solution with security in mind, the design should, by default, be optimized for security wherever possible at all layers. However, it is not a simple task, especially when it goes into higher layers OS, applications etc. For instance, application team may deploy their application software, and turn on every possible feature, to offer more services to the users. While, from a security point of view, the more features that are built into a piece of software, the more susceptible it is going to be to an attack. For example, if an attacker is trying to observe the behavior of the application, the more features and functionality turned on, the higher the possibility the attacker can observe. Simply, because, the higher possibility that the attacker is going to find some potential security vulnerability within any of those offered features.

The same is applicable to  operating systems, as they are commonly, contain a lot of services, features and functionality and many might be turned -on initially by the OS vendor. Therefore, there must be clear applications and OS security standards and hardening to limit what should be turned-on and turn-off all unnecessary services by default.

In the end, the main element to be protect as an asset today is the Data. With regard to data security in general, there must be a clear defined processes of data discovery and data classification.

Data discovery is a business intelligence operation, refers to the process of identifying and providing visibility into the location, volume, and context of data that can be structured or unstructured data stored in a variety of data repositories to look for patterns or specific attributes. In the cloud this cloud be a complex task, because data is commonly stored across disparate and varied systems, and possibly the data owners/cloud customer may not have a good awareness of where precisely data resides. However, data discovery within a Big Data solutions is a complex task that requires data owners, have very clearly defined scopes and objectives, along with the suitable tools and applications to help with this process at scale.

On the other hand, data classification is the subsequent process, that focus on determining the suitable security controls and policies required based on the data type/owner/criticality etc. These polices, can be derived either by the organization policy, legal or regulatory requirements (e.g. personally identifiable information PII) or combinations of both. Within a cloud environment, this is increasingly important due to possible exposure through multitenancy to unauthorized entities.

Furthermore, understanding the data lifecycle in a cloud environment is a crucial to design and build an architecture that covers all the aspects of data management and security across all the phases. The figure below illustrates the phases of data lifecycle, technically, the sequence shown below is not a mandatory requirement that data must go through it, it depends on the used solution and systems, where some steps in the lifecycle might be repeated, taken out of order, or omitted.

Taking the aforementioned cloud data lifecycle into consideration, combined with the following key foundational security principles, you should be able design and deploy a secure cloud solution, without deviating from the fundamental security approaches covered earlier in this blog:
foundational security principles:
Authentication, Authorization, Accountability, confidentiality and integrity, Availability

One of the best ways to understand how data is being processed and where are the potential points security principles need to be considered and integrated is to look at the data flow diagram of the applications.
“A data flow diagram (DFD) is a graphical representation of the “flow” of data through an information system, modelling its process aspects”
Note: as we know, Availability refers to a system that is capable to respond to its users’ requests within an acceptable time. Although availability is commonly used as part evaluating performance and business continuity metrics , it can also be thought of as a security design principle as well. Because, if an attacker was able to make a system unavailable, the company will typically lose revenue, reputation etc. even it has best security systems in place.
Last but not least, as we know, IT security in general (including cloud security) and threats to IT systems are constantly changing. This is due to the rapidly changing and evolving technical landscape, where new tools and approaches for attacks are always developing. Therefore, each time new change is made or new addition to the cloud solution is introduced, it must go through an impact threat assessments prior to the approval, typically considering what is called “Threat Modeling”.
“The purpose of threat modeling is to provide defenders with a systematic analysis of the probable attacker’s profile, the most likely attack vectors, and the assets most desired by an attacker. Threat modeling answers the questions “Where are the high-value assets?” “Where am I most vulnerable to attack?” “What are the most relevant threats?” “Is there an attack vector that might go unnoticed?”
“example: In 1999, Microsoft cybersecurity professionals Loren Kohnfelder and Praerit Gard applied Schneier’s attack tree analysis to develop a methodical means to consider potential attacks relevant to the Microsoft Windows development environment. The resultant STRIDE[ threat model”

Categories :
Marwan Al-shawi – CCDE No. 20130066, Google Cloud Certified Architect, AWS Certified Solutions Architect, Cisco Press author (author of the Top Cisco Certifications’ Design Books “CCDE Study Guide and the upcoming CCDP Arch 4th Edition”). He is Experienced Technical Architect. Marwan has been in the networking industry for more than 12 years and has been involved in architecting, designing, and implementing various large-scale networks, some of which are global service provider-grade networks. Marwan holds a Master of Science degree in internetworking from the University of Technology, Sydney. Marwan enjoys helping and assessing others, Therefore, he was selected as a Cisco Designated VIP by the Cisco Support Community (CSC) (official Cisco Systems forums) in 2012, and by the Solutions and Architectures subcommunity in 2014. In addition, Marwan was selected as a member of the Cisco Champions program in 2015 and 2016.

Leave a Reply

Your email address will not be published. Required fields are marked *

Order Now