Chess' Jez Turner and Matt Boddy from Sophos introduce the new offering from Sophos, Cloud Optix, which helps manage the proliferation of cloud servers in AWS, Azure, GCP and more.
Sophos is a vendor on top of their game. They have been acquiring cutting edge technology over the past few years in a very shrewd way, and integrating it into their portfolio.
- Artificial Intelligence
- Cloud Visibility (Cloud Optix)
- SOAR (Security Orchestration Automation and Response)
- MDR (Managed Detection and Response) with the acquisition of DarkBytes and Rook Security.
This has given them a very strong set of solutions and they’re a key player in all the spaces they operate in.
What this webinar will cover:
- What is Cloud Technology and why are people migrating to it?
- Sophos Research
- Cloud Optix
Times are Changing
There's a huge digital transformation underway, both in new and well established companies.
According to AWS, 84% of CIOs now have responsibilities outside of traditional IT, and these commonly include innovation and transformation. CIO success criteria is shifting from delivery (cost centre) to business-based measures (revenue generation).
The AWS platform has attracted a wide range of customers from the public sector through to start ups, including Airbnb, Spotify and Pinterest. Long established companies have also reaped the benefits.
Enabling Digital Transformation
Traditionally, when creating a new platform, considerations included:
- Data Centres: redundancy; where and how you're going to host
- People: both those needed to maintain equipment and to look after the software and the equipment, and also the resource needed to carry out the actual development
This is a long and expensive process.
Azure removes much of this. Instead, you just need to think about your developers - who can create in AWS, then hit deploy, providing a low barrier to entry for start-ups.
A collection of security and privacy tools is included within AWS, Azure and GCP to help keep data secure.
However, regular headlines in the news indicate that people are still losing data that's hosted in AWS, Azure, etc. The tools exist, but they may not necessarily be being implemented in the right way.
One reason may be the move away from the traditional structure, where there are a number of eyes on the same solution - i.e., the infrastructure manager, the network manager, the hardware & software managers, and the developer.
Now there's just the developer, whether they're pushing something out in an agile format, directly from GitHub to the cloud environment; or even just changing a database from on premise, to be hosted in the cloud.
These are primarily based on S3 buckets, which can be used to pull data in to one of your applications etc. The same goes for RDP in Azure, where you can host your data in the database and then pull from that directly to your software as a service. These are some of the cloud protocols that Sophos look at on a daily basis.
We tend to find out about data breaches only when an organisation has been notified to it, or they suddenly discover someone in their environment doing things they shouldn't be (e.g., Tesla spotted they were hosting Bitcoin mining servers in their AWS environment. The credentials to their AWS environment had been breached, because they'd hosted them on GitHub.)
Newspaper headlines revealing data breaches can come from journalists, finding customer data on the dark web. Sophos wanted to investigate how many times data may have been stolen before it gets found and flagged up, or before the hacker is discovered.
Sophos started with SSH as a protocol which they wanted to baseline, looking at SSH honeypots which could be used.
Cowrie was chosen, as it's straightforward to use and allowed Sophos to emulate an SSH server, logging everything that happened on the device, without exposing the device to the attacker.
Low Interaction Honeypot
Sophos began by looking at a low interaction honeypot.
The term honeypot comes from European folk law, where bears would sneak into a beehive to steal honey, and possibly get stung in the process.
In cybersecurity, a honeypot isn’t dissimilar to the folklaw, but inside this particular beehive, there is no honey, just a picture of something that resembles it.
Hackers' Usernames and Passwords
Hackers were provided with a login prompt, asking for a username and password; at which point they received an Authentication Denied message (as you'd expect with an SSH server if you'd failed to login.)
The hackers' usernames and passwords were logged to an Elastic Stack database, along with the location from which the attempts were being made.
Over 5,000,000 login attempts as root were recorded over the 30-day period. (Root is the username that's set up as default on a Linux device when it is spun up). Many of the attempts used defaults, e.g.:
Ubuntu - if you spin up a ubuntu device in AWS, it's set up with the username ubuntu - and this was used 2,585 times.
Nagios - a systems and network performance monitoring platform - another area that hackers are trying to exploit, to get into devices using the easiest possible method.
Time to the First Login Attempt
The hackers were quick - the fastest attempt to login to a device seen was 52 seconds.
These were on devices that hadn't been used e.g. for a website, without any DNS records other than the one provided to Sophos. Sophos simply clicked "Play" in AWS on a ubuntu server, and then spun up the Cowrie Honeypot, on Port 22.
The longest it took for an attack on one of the 10 honeypots was 1 hr and 44 minutes.
How Often Is Your Door Being Knocked?
One attacks had started, they built and built, until 13 login attempts were being received per minute on average - that's over 750 attempts every hour.
According to Gartner, through 2022, at least 95% of cloud security failures will be the customer's fault.
This isn't because blame is being attributed to the person looking after the data.
AWS is very secure by its nature. For instance, their big data centres, where they are hosting your platform, it's their responsibility to look after their hardware - but it's your responsibility to look after the protocols you're allowing to be externally facing, which is why AWS produced this Cloud Shared Responsibility Model.
Cloud Shared Responsibility Model
The Cloud Shared Responsibility Model clarifies that AWS are responsible for looking after your network; looking after your hardware; your host infrastructure and its physical security.
They are not responsible if you spin up an elastic server, if you've not put a good password on, or if you spin up an elastic server, and allow anyone to to log into it, from any location.
This is where technology is being developed to try to help.
Cloud Access Security Brokers (CASB)
Gartner has announced that this year there will be a Gartner Magic Quadrant for CASB. (Cloud Access Security Brokers) and Cloud Security Posture Management.
CASB is where you can monitor the cloud security management that you are using in your environment.
Cloud Security Posture Management, which is what Sophos Cloud Optix is, is about the security of your cloud estate. It’s not about what you're consuming, or the bandwidth of what you're consuming, it's about:
- what are you exposing to the outside world within your cloud infrastructure?
- how are you exposing it?
- what can you do to make that more secure?
- are you using multi factor authentication within Azure?
- are you using multi factor authentication on this account within AWS?
- what does your topology look like within this?
- how is the network traffic flowing?
- is network traffic flowing to this database which you're exposing externally
Sophos Cloud Optix Demo
Environment 1 - Honeypots
This is the environment which is hosting the honeypots. There are a number of alerts which have built up:
Critical Alerts - 1
Multi Factor Authentication is not enabled on one of the IAM users - one of the users who has access to the AWS environment
High Alerts - 10
Clicking into the high alerts (mapped onto the AWS cloud platform), we can see that currently any IP address is allowed access on port 22 to 10 of servers - these are the 10 honeypot servers.
This really simplifies the process of understanding what you have in the cloud, so that you can secure it. It shows where encryption is not set to on; it also shows there are 10 RDP servers with Port 3389 accessible from the outside world, i.e. any IP address can remote desktop into any of these devices.
This is giving visibility and understanding that these devices are going to be facing 10 login attempts every single minute.
Environment 2 -
This includes a number of individual environments, including Azure, AWS, Google Cloud Platform. These can be filtered, so the alerts for an individual environment can be viewed as required, and the entire inventory can also be viewed.
For example, we can see that within AWS there are 45 running hosts, of which 36 are public hosts; in Azure there are 38 public hosts, and the network is open to 87 devices. Clicking through gives visibility of what devices these are.
One of the most powerful aspects of Cloud Optix is the environment layout. This automatically maps out and draws a network diagram of the environment. We can click into each of the infrastructure environments.
E.g. looking at 6 instances within Bill's UTM environment - this shows some load balances and some AWS Sophos UTMs which are working together to allow ingress and egress of traffic to the environment. What we can also do, by clicking on, for example, the Amazon Linux device, is see that there is currently traffic flowing out to the internet on Port 80 - so we can understand everything about the traffic flow in this environment. This information is automatically generated and gathered from the logs within AWS and Azure. We can also see internal traffic.
The same goes for Azure.
E.g., The demo shows instances running in Azure. We can see the devices which are currently spun up in Azure, and the traffic that's flowing between them.
If we need to measure an environment against PCI DSS, or against GDPR regulations, we can use key compliance rules which can be run against our environment's logs.
E.g. this report, exported to a pdf, shows where compliance rules are not being met - in this instance, encryption of personal data; encryption of S3 bucket; encryption of EBS volumes. We can see where we are underperforming and document the necessary information for management reporting. The same goes for PCI DSS, if you hold credit card information.
Setting Up Your Environment for Cloud Optix
This is very simple, straightforward process - it shouldn't take any longer than 20-30 minutes.
Click "Add New Environment", you get a number of options:
- get the AWS CLI set up- there's a link which tells you how to do that
- link that with your AWS account, by providing the authentication code, to authenticate to your account
- download the Cloud Optix Script
- authenticate with Cloud Optix, automatically linking up to AWS and Azure accounts, so that logs are passed between them
- This is easier, as you have the CLI as part of Azure
- Click the PowerShell option in the top right-hand corner, where you can open command within the window
- At the bottom of the screen you'll have a command prompt that pops up
- Download the script by copying and pasting the script by using the wget command
- You can enable or disable logs here (There is an extra cost for the option to see how traffic is flowing within Azure)
- This requires some extra steps
- Open the Google Cloud Platform, run these commands, and you have an environment generating data, giving alerts of where things may be going wrong, giving an insight on where multi factor authentication is lacking; where devices are exposed. You can then take the necessary action.