 Good afternoon, everyone. My name is Julian Digby, Solutions Consultant at the EdgeServe. The topic of today's webinar is security in the cloud, security and access management in the cloud. So, next slide. So, essentially, it is true with all ICT systems that security must be considered. And the security of specific systems and the data that they hold should be reviewed on a case-by-case basis. But what we want to talk about today is essentially what the difference is when you're hosting those services in the cloud. So, in order to do that, it's worth looking at what's different. What's the key set of differences between what's a system that's hosted on your on-premise network versus in the public cloud. And I think it can probably be condensed down into these four bullets. So, the first one being moving infrastructure and data to a third-party facility. So, essentially, where you are hosting things on your own network, you're now hosting them on someone else's network, someone else's service, and someone else is looking after those on your behalf. So, that's obviously a very key difference. The second difference is accessing services via the internet. Now, this has various facets to it. So, if you are looking at a software as a service model, such software as a service is generally presented via the internet. So, a good example that a lot of people use is Office 365. Office 365 is accessed via the internet. And you have access to your SharePoint sites and your email and so forth over the public internet. At a different level, where you might be using platform as a service, services, the take, for example, a database service where you're responsible for the database, but the actual database application and the service supporting that are managed by a third party. And quite often that database is exposed via the internet. And so, the internet is the network used to connect that to perhaps another application. So, there is more use of the internet to drive traffic within systems as well as between users and systems. A third area where there's a key difference is a realignment of security skills across your staff. So, today it's probably true that you have ICT staff with a mixed skill set. And there might be a server expert. There might be a network expert. There might be a storage expert. And generally, they would collaborate together to actually deploy new services and so forth. With the public cloud, particularly, there's a need to share out the capability of those disciplines so that within one member of staff, you have at least a good appreciation of what needs to be done in all those three areas. So, we'll come on to that in a bit more detail. And the final area is sensitive management interfaces being exposed to the internet. Now, that is primarily, I guess, if you're using a vCenter, a VMware-type environment today, generally, the access to the console with the privileged access that that provides will be predicated on you being on your own network or from a key VPN location or other such controlled locations. It won't be generally available on the internet. It's because the cloud services are the management interfaces on the internet and understanding how to control access to those is pretty key in order to preserve the security of your systems. So, on to the next slide. So, going back to the first of those, so moving infrastructure and data to a third-party supplier. Essentially, you're extending your network to a third-party organization and you have good security practices within your own network and you really want anybody who's that you're extending your network to have a similar quality of security credentials or better, hopefully. So, there are various accreditations that a cloud service provider can exhibit, key one being ISO 27001. But there are some others that are potentially relevant in different areas, cyber essentials plus public services network accreditation. And if you're handling payment card infrastructure of any type, so you're taking payments with credit card compliance badge as well. And there are many others, but I think these are probably the key ones. Now, these aren't the last word on assessing somebody's security, but they are a useful shorthand. So, in order to pass an ISO 27001 accreditation, they will have been audited against a wide range of elements such as their internal processes, their security processes, things like separation of duties. So, I'll come back to you in a second. They'll be audited regularly. They'll be subject to penetration tests. And they'll have to demonstrate who's responsible for information within their organization and what the procedures are if a data breach is suspected and how they will interact with their customers in order to minimize the impact of such data loss. So, these are some key elements of ISO 27001, which you can be assured of by the accreditation and the regular audit of the organizations. That's not to say that if they don't have these badges that they don't follow these principles. However, it's a good indicator that someone, a third party, an independent third party has been in and assessed their capabilities and decided that they're up to scratch. So, I would suggest that these ISO 27001 is at least highly desirable. Just going back to the separation of duties. So, one of the concerns people have when moving data to the cloud is the idea that they're moving into facility where they don't know the staff. They have no personal involvement with anybody who works at that organization. So, it's a bit faceless and you're a bit concerned about who has access to your data. The separation of duties is essentially a principle that job roles are divided up in such that no one person has enough information and access to be able to exploit the data that's hosted on behalf of customers. So, for example, take an AWS case. The people who actually have physical access to servers and are able to actually go into data centers and touch servers and storage have absolutely no idea who is hosted on those servers. If they had a disk in their hand, they would not be able to tell you whose data it was and what it's for, what it could be used for. So, likewise, somebody who did know that would never get access to the data physically or logically. So, in order to exploit the fact that the organization was hosting your data, there would have to be collusion between various different individuals and so forth. So, that provides a significant protection against one-off rogue operators accessing your data. So, another part of moving data, particularly to a third party, is making sure that your data is encrypted. If it's appropriate that this data should not fall into other hands, then data encryption is recommended. So, there's two parts to this. There's data at rest. So, data sitting on storage devices. That wants to be encrypted. And there is a requirement to manage encryption keys at that point. So, obviously, there's no point in having a lock if you give everybody the key. Making sure that the people who have the key are suitably trusted or making sure that you are ultimately the only person with the key or access to the key is also a good approach. So, again, an AWS example, you're able to decide whether your storage devices are encrypted with a key that they provide through their infrastructure or one that you provide. And, depending on the circumstances, either may be appropriate. But it's recognizing that it is a lock and key process and that's looking after the keys is a key consideration. The other element of encryption is where data is being moved between systems and the appropriate, especially across the internet, the appropriate use of HTTPS and the TLS 1.2 encryption. There are various early versions of HTTPS, but TLS 1.2 is the recommended one currently. And that level of encrypted data, so not using straightforward HTTP access between systems is definitely the way ahead. So, moving on then. So, challenges of internet access services. So, initially, I just want to talk about the more software as a service type solution. So, a solution that like Office 365 or Salesforce and what have you, where access is over the internet, how do you go about providing secure access to that? So, in terms of access control, the two main things in your armory really are a strong password policy, ensuring that people use strong passwords that are hard to crack. And, you know, with software as a service, you know, ideally, the policy would be something that you could enable or it would be a default option that passwords must be strong. But also, where appropriate, multi-factor authentication. So, multi-factor authentication, so using something like Google Authenticator or another app on a smartphone or being sent a text message with a code in that you have to enter, those types of additional authentication have their place. Not all the time, perhaps. So, an example would be if you're accessing this service outside of your working office, outside of their network, then it's probably right that multi-factor authentication is enabled. But it might be possible that you can enable that whilst inside the organization, MFA isn't actually required and that gives you a slicker working practice, perhaps, when you're in the office. It's certainly something that Edge-U-Serve makes use of with Office 365. So, it's a bit of a theme that, so making sure that your security controls are proportionate and you're balancing the impact on users, on using the system versus the security of the system. And there may be factors like where that user is working from that actually tip the balance towards or away from things like multi-factor authentication. Next slide. So, another element of the internet access services is that with a typical on-premise arrangement, you would have typically company-owned devices on a company-managed network accessing data on those services. And it's generally, it's not impossible, but data will generally be held within the organization's assets on the network and on the infrastructure. And it won't find its way onto other systems and devices. Now, with Office 365 as an example, the access to data held on this SaaS solution, this software as a service solution, by default, it's possible to access that from any device with an internet connection onto Office 365. And that might be just to view a document and that might actually stay within the system, but potentially you could download that document and that document would then exist perhaps on the hard drive of another computer. That computer might be one that's not sanctioned for use by the organization and so it might be a home computer. Worse, it could be something in an internet cafe, if such things still exist. Certainly shared access computers exist. And proliferation of data and data lost through that process is not ideal. So what can you do about it? So various solutions will help you here. So in an Office 365 environment, you can control which devices can access the service. So you're able to, in the case of Microsoft's stack, use a product called Intune to define which which devices are able to access the service and also what their security profile has to be in order for them to have access. So they have to have up-to-date antivirus to have their firewalls on that type of thing. So essentially managing the security stance of the devices that are accessing your data, you can also control how data can be accessed. So within SharePoint Online, it's possible to view documents within the web portal and not download them. And you can actually prevent download. If it's appropriate, you can say, well, this document or the documents on this site are sensitive in nature and should not be downloaded. And that would prevent them appearing on the hard drives of third-party computers. So that's a good tip. Another tool in your armory is audit. So audit doesn't prevent data loss, but it would let you see when it has occurred. So understanding when data is downloaded to wear and buy whom gives you a way to review what practices are occurring within your organization and potentially address the human factor and ask your staff to refrain from doing that. I think in a lot of cases where data does find its way out of the organization, it's not really for nefarious purposes. It's generally because people don't realize and don't appreciate that data might be cached on a hard drive or the downloads folder gets full of your on your home PCs, full of work documents. In a lot of cases, your staff wouldn't appreciate that initially. So I think an acceptable use policy that details what shouldn't be done and why not. So just make sure it doesn't appear overly draconian. You get more buy-in that way. It can go a long way to actually addressing this sort of issue. On the flip side, the flexibility, especially if you've got some elements of mobile workforce of being able to access organizational documents on mobile devices and laptops and so forth whilst outside of the office, that's obviously a clear winner and something that's highly desirable in a lot of cases. So you don't want to curtail that and stop that from being available because of security reasons. So again, it's all about proportionality and making sure that you have the right balance of usability and security. And like I say, all of these according to the sensitivity of data and risk assessment. So understanding what your appetite for risk is with any given system is pretty key. So moving on to securing cloud services. So this is really under that third bullet point at the beginning about that mix of skill set and the cloud security skill set being spread across a broader set of people. So rather than a sort of siloed access, any one individual would have security responsibilities in a number of areas. So the security of cloud services really relies on the security features of the service and crucially how they are configured. Now the public cloud providers operate what they call a shared responsibility model. So this diagram is the AWS diagram to illustrate this. They are responsible for the security and the upkeep of everything in orange and it's the customer's responsibility to look after everything that's been in blue. So ultimately they're responsible for compute storage, database, networking, software that those run on and the general networking infrastructure around regions where things are hosted, availability zones and so forth. So they provide the platform to you and it has a set of features and capability that are available for you to configure to ensure your security. So above that the elements in blue at the bottom there are client side, data encryption, data integrity, authentication, server side encryption, networking, traffic protection and so forth and then moving up through operating systems, firewalls, identity management and so forth. So essentially there are a lot of elements that need to be configured as there are on an on-premise service that can make the difference between a secure system and otherwise. I guess a key thing that's worth considering is in an on-premise environment ultimately your edge firewall is the last line of defense where your networking experts can prevent data transit that they didn't see an appropriate reason for. So I think when it comes to public cloud having that level of understanding on all or a majority of people whose job it is to configure servers and networks within the public cloud is pretty key because they can by using a particularly a Paz solution it's possible to misconfigure and have things exposed to the internet and unauthorized users. I think it's been quite a bit in the press recently about Amazon S3 buckets and S3 is an internet access storage service. A bucket is essentially a folder if you like and by default when you configure them they're open to everyone on the internet and there's quite clearly a set of steps that you take that would lock that down to particular users in particular locations and so forth. But there are people who have made a point of going out and finding S3 buckets that seem to have things in them that you wouldn't generally want to share with the whole world demonstrating that some people are deploying these services without properly configuring them. So not to create undue concern but essentially the requirement is to make sure that the skillset exists within your organization to adequately secure the services that you're using. And we talked about redistribution of skills and shared responsibility. I think that can be dealt with with additional training but also peer review. So obviously there will be people in the organization with a better understanding of some things than others and whilst you're in perhaps a transition phase making sure that the team works together to identify the most secure way of deploying something. And then a security review, regular security reviews, audits, penetration tests etc are advisable just to make sure that what has actually been deployed has been done so in the appropriate way. This graphic on the right hand side here is one of the configuration windows in the Azure portal. And if you can see part of the way down, this is to set up a virtual machine but it's asking you about virtual networks, subnet, network security groups and so forth. And further on it will allow you to configure rules for network security and so forth. So there's quite a lot involved when you create a VM. It's not just standing up a server it's doing all the associated work as well. In the UK ultimately what you're trying to deliver is adherence to the NCSE cloud security principles of which there are 14. So I wouldn't worry about reading these for the moment but you know if you Google cloud security principles you'll get the list and you'll get recommendations on how is it deployed. But it's worth saying that templates exist for deployments that actually meet those cloud security principles. There are AWS templates and there are Azure templates. So here we have the AWS one on the left and the Azure one on the right. I don't expect you to study these as they're on the screen here but just to demonstrate how that they're here there's a lot of backup content that goes along with these breaking down exactly how the infrastructure meets those cloud security principles and also identifying any additional considerations that you should take in order to maybe improve security or responsibilities that you have under that shared responsibility model to make sure that they're sufficiently secure. And then whilst we're talking about the feature sets of the public cloud you know there are tools and systems that are easily deployed to prevent issues with particularly the fact that more of your systems might be exposed to the internet might have an internet interface than you've had previously. So obviously web application firewalls will sit at the front end of your application and monitor the traffic in and out of your application and flag up the most common issues that are seen security issues are seen and either proactively put in controls to fix that or alert you as the administrator of the system that there's additional security required or that you're experiencing some sort of attack. The graphic on the right is meant to illustrate a distributed denial of service attack so DDoS could be a real threat depending on your organization so if somebody takes it upon themselves to attack your web services websites to prevent you from going about your business just to cause you problems then DDoS prevention will help you. The good thing about the public cloud is it has a level of that built in but in its default state it protects the platform as a whole so if there's an attack against Azure or an attack against AWS the staff will do what they can to mitigate that. You can then subscribe to additional levels of DDoS protection which will focus on your particular set of servers so if you have four web servers and they're under DDoS attack that wouldn't be highly visible to the Microsoft Azure platform because it's four servers and it's not 4,000 servers but by buying into that service you're allowing them to analyze traffic on your particular servers and prevent DDoS attacks. Again both Amazon and Microsoft have security services so there's Amazon GuardDuty and others as your security center that will advise you on the security status of your implementation whether you are experiencing any form of attack and will provide advice and automate the device as to what you should do to prevent either future attacks or one that's currently underway. You're buying into an infrastructure that has experts running it and can give you expert advice so you're extending your security skillset by subscribing to these services. The last point on the first slide was around sensitive management interfaces so by this I mean any interface that allows you to perform major reconfiguration of resources and privileged access to data including the ability to delete data so obviously those interfaces exist and you can do an awful lot of damage through those interfaces so if you imagine in an on-premise environment you know someone with administrative rights could also do quite a serious amount of damage but it's harder it's not all in one place it's harder for them to completely destroy what you have so key thing to do is to protect those interfaces now by default you just need a username and password to get in that is not a good way to leave them so when you deploy these sorts of services there are three approaches really ensure that people are using strong passwords and that you're not using root accounts to access and configure services on a daily basis enabling two-factor authentication so in the case of Amazon web services you can do this via the Google Authenticator app on a mobile phone obviously gives you a more secure interface but also restricting access to the management console to white listed IP addresses you know that takes a bit more configuration but it's available in both as your and AWS and probably many other services making sure that you don't box you know prevent your the access that you need from being available but ensuring that you know essentially only no networks that are able to access your management interface those those levels of security on those interfaces are wholly appropriate for everyone so role-based access control is essentially the it's a way of implementing the least privileged policy so making sure that any user given their role only has the right to do what they what they are strictly required to do and that means that you minimize the number of people who are able to do serious damage either by accident or on purpose and and you know obviously it's good practice on-premise solutions as well I think you know going back to the previous comments about the about management interfaces being available and being able to configure all things in some way through those interfaces the judicious use of role-based access control is pretty key to make sure that you don't have too many people or ideally anyone that could actually destroy your entire IT system with that in mind it is recommended that some form of failsafe account is used excuse me so essentially you know with it within a cloud service you would back up your data to another another location much as you would with an on-premise solution so in on-premise world you might might move tapes or discs or have discs in an alternate location in the public cloud you would replicate or back up data to a facility that you know to be in a different data center and and that protects from system issues really a failsafe account protects you from the human issues of somebody catastrophically doing the wrong thing by mistake which might occur or someone catastrophically doing the wrong thing because they're about to hand the notice in you know they're a disgruntled employee of some sort and you know essentially they have the ability to do that and they're going to choose to use it and so previous comments still apply so you know trying to reduce the the number of people who are able to do that to to to zero ideally um but in terms of a failsafe account it would be an account that only can only be accessed by um through authority from a senior executive or you know uh you know the senior information responsible officer Syro might be the appropriate person uh or might be a finance director or someone um someone who probably on their own doesn't have the ability to to access the account because they don't have the technical uh skill perhaps um but they they can be the the uh gatekeeper of the of the failsafe account and prevent access on a day-to-day basis but if you absolutely need it if you need to rebuild your um your deployment in the public cloud um uh from scratch from from the backups that you you hold um then uh they would be available um and sometime down the line you'd be up back up and running so um just to summarize um we talked about um security in terms of you know the the specific nuances of security when it comes to deploying cloud services um so security is a shared responsibility um between you and the cloud service provider uh cloud security risks can be managed though and there are a wide range of controls so certainly do not intend to worry you by this presentation um as for on-premise deployments uh risk assessments are important so understanding um where the risks are where the threats are um precisely what you're doing to mitigate those risks uh is is pretty key um so you might do that um uh you know at a sort of high level of granularity so for for a for a set of systems there might be specific systems uh holding particularly sensitive data that you you want to do a full risk assessment um on the way it's deployed in the cloud um staff cloud skill sets need to be developed to safeguard your systems and data uh it's a it's a new set of skills um even doing the same thing uh as you do on-premise but in public cloud there are different buttons to press and boxes to tick so training is key to make sure that the sufficient security is deployed um and privileged access must be controlled and secure so um look uh look to uh deploy the least privileged policy um and make sure that people only have the access rights that they need and that is that i do apologize for the delay at the beginning um but if there are any questions i think i've probably got time to take some questions so i've got uh hand raised indicator next to ben kestiv admin access um to whitelist on office 365 uh i think that was ben's question so um so yes so the the particular feature of office 365 that i was alluding to is something called um uh conditional access um that can be configured for um any of the microsoft cloud services so uh in the case of the azure management console you do it for that um but you can also do it for um office 365 services um so you can whitelist based on uh ip address should you wish um you can also vary uh the security stance so you can you know you can enable um um no mfa uh from an internal network and mfa if you're on an external network but it's uh if you want to google it it's conditional access um that's the the element of office 365 is actually a feature of azure active directory um that enables that okay any other questions well i think that's it i don't have any more questions on my screen so thank you every very much for attending i want to last apology for the technical edge at the beginning um every day's a school day okay thanks very much everyone bye