Creating an ISMS that incorporates AWS (2015)

Introduction

The migration to the cloud is now in full swing and AWS is the biggest player in this arena with the most scalable and mature platform to date. However there are still many security considerations as the system is dynamic and ever evolving.

What is ISMS?

An ISMS is a set of policies related to information security management or IT related risks. So fundamentally it’s a risk management system mostly comprising a set of documents that govern the practices and process around risk management.

The reason for including AWS as part of your ISMS is because if you are using AWS it has now become an extension of your infrastructure and it needs to be treated like an extension of your DMZ off premise.

It is common knowledge that a good majority of security depends on people and is not bound by technology and AWS is just a technology grouping that also requires guidelines for people to adhere to when leveraging the remote resource. Your overall security posture is only as strong as your weakest link and if you have not thought or covered AWS in your ISMS it might represent this weak link so it’s important to consider the cloud and the security aspects around it as if they were just an extension of your network.

This means that similar or the same controls apply irrelevant of the location of the data and the compute environment. There is no reason that an organisation should be able to accept more risk because their data and compute is not onsite. The concept of security should not be seen as a snapshot but a dynamic running process that is constantly being evaluated.

What does an ISMS do for you when using AWS

The formation, maintenance and continuous update of your living ISMS provides a springboard and a robust indication that an organisation is using a systematic and structured approach for the identification, assessment and management of information security risks irrelevant of the network boundary.

Critical factors of ISMS when using AWS:

In security the key CIA principle will prevail even in the cloud.

  • Confidentiality: Protecting sensitive hosted AWS information and systems from unauthorized access.
  • Integrity: Protecting hosted AWS information and systems from modification by unauthorized users.
  • Availability: Making and ensuring that the Hosted information and systems available to authorized users.

These key principles will have to be addressed in the ISMS so that your AWS platform is available, the data and systems remain confidential and have integrity.

Key elements to address in your ISMS when using AWS

  • Ensure that you master passwords and keys are kept safe and offline, an HSM is recommended or printing them out and storing them in escrow and in your corporate safe is a viable option. This includes and is not limited to any recovery accounts and credentials associated with these accounts.
  • Ensure when and if available that strong authentication is used or longer passwords, 14 characters + are recommended. Additionally when authorised users are accessing systems hosted in AWS they should be using strong authentication and the system should be treated with the same security as anyone using remote access platforms to the corporate network. If your organisation is not yet using strong authentication, now is a good time to implement something that is fit for purpose. Passwords are too weak these days. Multifactor authentication is a must.
  • It is important that these accounts, credentials and details be reviewed by trusted personnel on a periodic basis, the recommendation is every 6 months and also by substituting the individuals so there is segregation of duties and cross pollination of skills, this limits the risk of only one person knowing how the platform works and also is best practice. There should be governance around this process so that senior management can sign off that this is being followed and done so that the organisation is assured that the supplier has the most recent company contact information and that the recovery process works.
  • Ensure that you have rigorous patch management for your AWS platform that covers the TCB. This includes all the “hardware” or virtual platforms, firmware if any and the software (application and operating system) and also includes the hypervisor if any and any patchable platforms. Do not leave anything out like third party apps as said before in this article, in security you are as strong as your weakest link.
  • Harden your platform on AWS, ensure that you build a secure base image (AMI) and also remove any unused software and services from the AWS instance so that your attack surface area is minimised, the smaller the surface area the better.
  • Protect the guest OS and if possible the host OS, monitor and alert and use IPS/IDS if possible.
  • Use a firewall, a firewall is a fundamental part of your security defence and should be installed on every guest OS in my view. In this way everything is closed by default and you have to make a conscious decision to open something up. As you already know this should be properly managed and documented so there is change management and also a regression plan if something is changed. This strategy also protects each guest in the event that a worm creeps onto another connected system inadvertently.
  • Using a FIM, File Integrity Monitoring is important, not only will it tell you that a file has changed but some technical controls can stop critical files from changing and allow you to define who can change what files. This is now common place in banking and governmental networks and there is stronger evidence that it should also be common place in the cloud. Use this control, I am sure it will serve you well, and ensure that your ISMS cover this aspect of security.
  • Always encrypt sensitive information, this is a simple control that if implemented 90% of all data leakage would not have taken place. Your ISMS should be robust in this aspect and should cover the encryption of all data at rest in AWS and data being transmitted in any form including backups.
  • Keep conducting constant vulnerability basements and penetration tests, after any changes these should also be considered to ensure the integrity of the systems and platforms hosted in AWS. This is best practice and many organisations are not taking this advice and it’s just a matter of time till they are plucked from the web by prying bad actors.
  • Keep evolving and remain aware of the threat landscape, it’s like a changing tide and every day is different, so your defence strategy has to be adaptive and capable. So keep improving the defence.

Conclusion

It is important to note that your data asset needs to be managed no matter where it is, it should not be harder to manage just because someone else does the compute. In fact it should be easier. Security remains a key concern for organisations and now that the ISMS incorporates your AWS hosted platform you can be assured that at least you are aware of the gaps and have a platform to manage and mitigate the known risks. Now the main objective will be to implement the appropriate measurements in order to eliminate or minimize the impact of various security related threats and vulnerabilities.

About The Author

Leave a Comment

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

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top