PIA - CyberEye - Cloud Security
PIA - CyberEye - Cloud Security
Final project
Datos:
Maestro: Ing. Adrián Israel Flores Rodríguez.
Grupo: 004.
Unidad de aprendizaje: Seguridad en cómputo en la nube.
Disclaimer:
This document is confidential and contains sensitive information, it should not be printed or shared with third
parties. All rights are reserved to CyberEye. ©
2 Content 3
2.1 Background of CyberEye ©. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Bussines line. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2 Business processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.3 Mission. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.4 Vision. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.5 Our Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Scope of the project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 Company systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.3 Current Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.4 Why we chose a cloud model? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Implemented technical controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 Azure Identity Access Control (RBAC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3 Azure KeyVault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.5 SSH Hardening Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.6 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.7 Azure Application Gateway (WAF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.8 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.9 Azure Monitoring Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.10 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.11 Azure Backup VMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.12 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.13 Azure Auto-shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.14 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4 Deployment details and specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3 References 32
1
1 Introduction
The security professional has been called by the CyberEye© Company’s Manage-
ment to migrate part of his IT services to the public cloud. The general objectives
that the company found are:
• Start a process of “digital transformation” but in such a way that the Security In-
formation is not compromised, for this reason the recommendations or technical
controls of the security team should be implemented.
• Saving Costs for the IT Infrastructure and Management of this.
• Could have elasticity for attend complex process and ensure the operations in the
high transactionality of their processes.
• Ensuring business Information Security policies and compliance needs.
The following are some important organizational aspects of who CyberEye © is.
2
2 Content
Our line of business is quite broad, since it covers the supports of physical devices
such as office computers, laptops, some mobile devices and telecommunications
equipment such as routers and switches but actually we are now experimenting on
the e-commerce side with online stores. We do not perform processes or logical
configurations such as the design of entire architectures or complete router configu-
rations. We provide maintenance and support, not development.
The process line is too simple, there are two forms of contracting, for events which
can be indeterminate with respect to time and work, for example preventive mainte-
nance to a device or initial configuration, this process includes a contract where it is
specified what is the that you require, and our support team will come if necessary
to provide the necessary support and / or maintenance. the time varies depending on
the problem and the assistance is no later than 3 hours, the reporting hours are dur-
ing business hours and the service is provided exclusively under contract. The other
type of contract is the one-off contracting by time, this contract determines that our
company will offer the service of support and maintenance whenever it is required
in time of immediate answer, at any hour and any day. The contact for this type of
service can be through tickets or calls, which by providing the ID of the company
generated by us, we can speed up the time and go as quickly as possible. Our support
experts will come, do what is necessary to solve the problem and give feedback based
on how to take better care of the equipment or recommendations for an upgrade.
3
2.1.3 Mission.
Services company dedicated to meeting the technical support and maintenance needs
that the client requires and needs, thus increasing the performance of their computer
equipment quickly and comfortably in addition to increasing their life time and form-
ing an approved system, through diagnosis , recommendations, maintenance and
analysis on possible problems and their respective solutions.
2.1.4 Vision.
Honesty: We adhere to a behavior based on frankness and fairness so that our clients
feel safe and workers feel safe working with us.
Innovation: We are committed to always looking for the newest and best optimized
solution for the different problems and needs that customers have.
Overcoming: Growing day by day will always be our goal, to improve ourselves
and forge our entrepreneurial spirit is a value that we carry in our hearts
4
2.2 Executive Summary
For this project we will be migrating to the Azure public cloud and in an IaaS cloud
scheme the web server infraestructure of the company CyberEye, this company has
multiple areas as we will see in the following sections, but other security specialists
will be responsible for the on-premise parts of the company, while we, the cloud
security specialists, were given the task of migrating and improving security with
everything related to the organization’s web server, which is about to start an online
store and needs certain security controls in order to have a secure and reliable start
for its customers.
5
2.2.2 Company systems
The main objective of carrying out this migration plan of on-premise services to the
cloud is to have greater availability, security, scalability of the infrastructure, as well
as a decrease in long-term costs in the company, all this implemented in the services
provided by Azure.
The area of the company where we provided the cloud migration service was the web
server area where they had several services mounted locally on their servers, the web
application, a mail server, the ticketing application and the accounting application,
the disadvantages and problems they had were the following:
We would take care of migrating the web server to the public cloud in a cloud IaaS
(Infrastructure as a Service) environment, which would streamline the productivity
of CyberEye’s online store in addition to bringing advantages such as:
6
2.2.3 Current Architecture
The main problems regarding the web server is that cybereye had practically no ar-
chitecture or security strategy defined, in addition to the high costs in electricity and
the high costs of mantainance, the scheme was simply a connection from the web
server to the internet and the internet to the internal infrastructure of the company as
you can see in the following image:
7
2.2.4 Why we chose a cloud model?
To solve all these problems at once, we, as cloud security specialists, decided to
implement a IaaS model in the public cloud of Microsoft Azure, which provides us
with many facilities and tools to cover all the beforem mentioned problems:
By this point we had already covered the general issues, i.e. excessive electricity
costs as well as high equipment maintenance costs, but we still had to cover the cloud
security strategy by implementing some technical security controls, which could
better secure and hardenize the security on the online store hosted on our CyberEye
server.
8
In the diagram below, you can see the technologies that helped us implement the tech-
nical controls, improving the security of the web server inside the perimeter towards
CyberEye’s internal network:
In the following section we will mention and explain the approach of these security
controls and which are the benefits of having implemented them in this scenario,
since each one of these controls has a very defined and specific function.
9
2.3 Implemented technical controls
Protect your applications and data at the front gate with Azure identity and access
management solutions. Defend against malicious login attempts and safeguard cre-
dentials with risk-based access controls, identity protection tools and strong authen-
tication options—without disrupting productivity.
2.3.2 Implementation
We use a Role Based Access (RBAC) to have a correct management of the resources
used in the Azure public cloud environment, this because being a numbered team
in CyberEye, not everyone has to have access to the most critical resources in this
migration.
Implementing the Identity Access Control helped us too much for this function, let’s
see a practical and real case why we decided to put this control in operation:
We have 3 contributor users and a reader user, this type of users in Azure can only
list and read the resources they are part of in the resource group, this is very useful
because if we have an employee in charge of managing only one resource we can
assign him the reader grade in all the others.
Figure 6: Users and his roles on the Azure CyberEye-Enterprise resource group.
10
What would happen if this user wanted to access a resource where he should not? For
example a very critical one, which is our Azure KeyVault, where all the important
keys of the organization are stored, here we can see what is the result of this:
Even if this user can read certain resources in the resource group, KeyVault, being
such a critical resource, does not even allow this option to this type of user, which is
a good security measure.
Figure 8: Action denied when the user try to list the keys.
11
2.3.3 Azure KeyVault
Azure Key Vault helps teams to securely store and manage sensitive information such
as keys, passwords, certificates, etc., in a centralized storage which are safeguarded
by industry-standard algorithms, key lengths, and even hardware security modules.
This prevents the disclosure of information through source code, a common mis-
take that many developers make. Many developers leave confidential details such as
database connection strings, passwords, private keys, etc., in their source code which
when gained by malicious users can result in undesired consequences.
Access to a key vault requires proper authentication and authorization and with RBAC,
teams can have even fine granular control who has what permissions over the sensi-
tive data.
2.3.4 Implementation
This control is closely linked to the previous one, since only authorized users can view
the contents of the keys in plain text, this time we removed the role type ”reader” to
the previous user, and we put it as owner, now let’s see what are the changes that are
when performing this action
12
Now things are different, as we can see in the image below, the user can not only list
the content, but also view the key in plain text within this content.
The azure KeyVault is an excellent way to keep our secrets safe, from passwords to
certificates, with a high level of security because we can implement this control so
that we do not even see the content of these keys, and are used behind to log us into
the services.
13
2.3.5 SSH Hardening Login
SSH or Secure Shell is the popular protocol for doing system administration on Linux
systems. It runs on most systems, often with its default configuration. As this ser-
vice opens up a potential gateway into the system, it is one of the steps to hardening
a Linux system. This article covers the SSH security tips to secure the OpenSSH
service and increase the defenses of the system.
Instead of using a normal password-based login, a better way is using public key
authentication. Keys are considered much safer and less prone to brute-force attacks.
Disable PasswordAuthentication to force users using keys.
2.3.6 Implementation
The SSH service is of great importance to remotely manage the virtual machine in
this case this VM is the server that is hosting our online store, but we must be careful
about how we allow access to this useful service.
Therefore we restrict access through passwords and set to only public key access,
which is brutally more secure, as it completely denies brute force attacks, first we use
a script that our colleague had made earlier, its functionality is simply to modify the
ssh configuration file to change the way to access SSH:
#!/bin/bash
#Author: kxisxr
greenColour="\x1B [0;32m\033[1m"
endColour="\033[0m\x1B[0m"
redColour="\x1B [0;31m\033[1m"
blueColour="\x1B [0;34m\033[1m"
yellowColour="\x1B [0;33m\033[1m"
purpleColour="\x1B [0;35m\033[1m"
turquoiseColour="\x1B [0;36m\033[1m"
grayColour="\x1B [0;37m\033[1m"
14
echo -e ' '
fi
if [ $value == '1' ]
then
sed 's/ ChallengeResponseAuthentication no/ ChallengeResponseAuthentication yes/g' /etc/ssh/
sshd_config | sponge /etc/ssh/sshd_config
else
fi
Extract 1: Script to automatically enable and disable the password login on Linux.
15
On the left side I used the script to disable access by password on the web server
hosted in the cloud, and on the right side we can see how when I try to log in by ssh
from my local machine to the cloud server, I am denied access and asked for access
by public key:
Reversing these changes, and leaving the default SSH access (which is by password)
we see that immediately after providing a correct password it lets me enter the web
server.
16
But, what problems can bring us to leave the SSH access by default on a web server,
this can bring us headaches as the famous ”brute force attacks” of which I will
demonstrate below:
Again, once SSH password access is disabled, this attack is completely mitigated:
Figure 14: Brute-force attack failed, since access is enabled only by public key.
17
2.3.7 Azure Application Gateway (WAF)
18
2.3.8 Implementation
This control was one of the most difficult to implement, since it requires a separate
public ip, then configure the Application Gateway in WAF mode and then make the
respective configurations so that all requests that reach the web server, are passed
through this new WAF, and thus give us a response after analyzing the packets in
depth if it is a valid packet or if it is an intentional attack to our website.
Once configured, it is important to set the WAF in prevention mode, as this way it
will have a proactive approach and will block malicious inputs on the fly, whereas
in a purely detective approach, the WAF would inform us of attacks but would do
nothing to prevent them.
19
Once this is established, we can take a look at the defined rules, we chose the OWASP
3.0 rule set which has 12 different rule category sets to deny attacks such as SQL
Injection, XSS, LFI, among others.
We can also test our web application and depending on the results, if we were able to
perform a successful attack, we can put in a custom rule the attack vectors to block
them.
20
Now let’s see a practical example of how an attempted SQL injection attack on our
login panel off the online store was blocked:
Figure 18: Injecting the malicious payload ’or 1==1– - to bypass the login screen.
21
Now let’s see what the result is after activating our waf in prevention mode:
If we pay attention to the error message it mentions that we do not have authorization
to view the page we are trying to access, which is the bypassed login, also if we go
to the app gateway resource, we can see this attempted attack in the logs and activity
logs.
22
2.3.9 Azure Monitoring Alerts
Metric alerts in Azure Monitor provide a way to get notified when one of your met-
rics crosses a threshold. Metric alerts work on a range of multi-dimensional platform
metrics, custom metrics, Application Insights standard and custom metrics. In this
article, we will describe how to create, view, and manage metric alert rules through
Azure portal and Azure CLI. You can also create metric alert rules using Azure Re-
source Manager templates, which are described in a separate article.
2.3.10 Implementation
To test these alerts we used a Linux program called stress which allows us to increase
the workload of the virtual machine, in terms of CPU, HDD and ram memory, which
would trigger our alerts.
23
Figure 22: Stress test to trigger the alerts.
Thanks to this program we were able to trigger alerts in a 100% controlled environ-
ment, as we will see below.
24
Once executed the stress test we can see how in the azure panel in the alerts section
these are correctly reported to perform the necessary actions in this regard.
Figure 25: Information on why alerts were triggered in the azure alerts dashboard.
25
2.3.11 Azure Backup VMs
Azure Backup provides independent and isolated backups to guard against unin-
tended destruction of the data on your VMs. Backups are stored in a Recovery Ser-
vices vault with built-in management of recovery points. Configuration and scaling
are simple, backups are optimized, and you can easily restore as needed.
As part of the backup process, a snapshot is taken, and the data is transferred to
the Recovery Services vault with no impact on production workloads. The snapshot
provides different levels of consistency, as described here.
2.3.12 Implementation
We implemented this control to guarantee the information of the web server, by im-
plementing a policy that will perform a daily backup at 3:00 a.m., thus guaranteeing
the integrity of the information.
26
Once this is done, we can restore the virtual machine to any backup point we have
stored, which protects us against data leakage or data damage, i.e. this policy and
specifically this control is especially good against ransomware.
27
2.3.13 Azure Auto-shutdown
The auto-shutdown feature in Azure allows you to configure the shutdown sched-
ule for virtual machines. Based on the schedule you set, the Microsoft Azure VMs
automatically shutdown.
Sometimes the virtual machines that you create in Azure don’t need to be running all
the time, and specifically in the phase we are currently in at CyberEye, since we are
in the preparation phase and the online store is not yet in production.
2.3.14 Implementation
The auto-shutdown control was an important part of the implementation because Cy-
berEye was in the preparation phase to implement the online store (and not in produc-
tion), because of this we could shut down the virtual machine to meet compliance,
security and of course cost savings.
28
As we can see in the image, azure sends a warning email half an hour before the
scheduled time for the automatic shutdown, and mentions a series of actions that we
can do before this happens, such as postponing the shutdown or simply canceling it.
29
2.4 Deployment details and specifications.
The following are the specifications implemented for the virtual machine where it is
hosted the web server, and which hosts CyberEye’s online store
30
In the image below we can see the final result of the implementation of the web
server in Azure Cloud, with their respective resources and technical controls that we
implemented in this IaaS model.
Figure 30: Final resources and controls implemented on the cloud public model.
31
3 References
Bibliography/References:
https://azure.microsoft.com/es-mx/services/virtual-machines/
https://docs.microsoft.com/en-us/azure/key-vault/keys/about-keys
https://docs.microsoft.com/en-us/azure/web-application-firewall/ag/ag-overview
https://docs.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-
overview?WT.mc_id=Portal-Microsoft_Azure_Monitoring#create-an-alert-rule
https://docs.microsoft.com/es-es/azure/security-center/adaptive-application-controls
https://www.netreo.com/microsoft-azure/what-is-azure-hypervisor/
https://docs.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-
configuration
https://docs.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-crs-
rulegroups-rules?tabs=owasp32
https://www.cyberciti.biz/faq/stress-test-linux-unix-server-with-stress-ng/
https://www.stephenhackers.co.uk/azure-auto-shutdown-save-greyed-out/
https://azure.microsoft.com/es-mx/overview/security/
Daniel Carter, CCSP® Certified Cloud Security Professional
32