Recommendations for cloud security: do the basics and plan for the worst
by Jon Topper
Recommendations for cloud security: do the basics and plan for the worst
Don't keep secret or sensitive information in plain text; ensure regular patching; deploy 'least-privilege' to staff; use 2FA and secure password protocols; plan for what to do in the event of a breach and don't try to cover them up.
The number of high-profile data breaches has accelerated rapidly in recent months. Amazon revealed that over 100,000 documents containing highly personal information such as passports and security IDs were found in an unsecured S3 bucket, and NCC Group made public attacks that had targeted sensitive data belonging to one of their clients, a UK government military contractor. Last year, Uber, Equifax and Cash Converters all suffered major breaches exposing customers' personal data.
It's a concern for tech companies dealing with sensitive information, and with the EU's General Data Protection Regulations (GDPR) coming into effect on May 25th, it is increasingly important that businesses do everything possible to mitigate against the range of threats.
Many data breaches are due to companies allowing themselves to be vulnerable to attack. Hacks infrequently happen because perpetrators are looking for specific information, but rather because they've identified the lowest hanging fruit, scanning for anywhere where there are gaps in security. So what can companies do to make sure they're as protected as possible?
Better management of secrets:
Companies need to ensure that anyone handling secret or sensitive data like API keys and access tokens - such as developers - do not keep these in plain text, either in version control systems or on servers. Where possible, they should use rotating, time-limited credentials. For example, AWS offers ‘instance profiles', which let you assign permissions based on server cluster membership. Software running on these servers can examine a link-local HTTP service and pick up a time-limited access token that can be used against other AWS APIs.
For secrets that need very secure storage, a solution like Hashicorp Vault is a great option. These solutions provide security primitives via an API, and can be used as an encrypted key/value store and an X.509 certificate authority. Through an ecosystem of plugins, they have the ability to create temporary access credentials for a variety of systems. Applications that need database access on-demand can ask for time-limited access, and get credentials back that will be useless to attackers after 15 minutes.
Organisations also have to make sure they don't forget to encrypt all storage in laptops, USB keys, and cloud services, as these are easy entry-points for a potential breach.
Easily the biggest cause of security breaches is due to not keeping software patched against known vulnerabilities. A regular patching system is crucial for any company running systems, and it's important to continue patching servers until they're completely decommissioned even if they're no longer in use - a lesson learned from the Cash Converters breach where an old server was left running.
This isn't just for operating system software - if building software for the web, companies often rely on libraries provided by other people, where security vulnerabilities can also be found. If a business runs systems or writes software, it needs to have a regular policy for updating both systems and libraries. If contracting third parties, there should be provision in the contract for this responsibility too.
Another aspect to take into consideration is making sure that processes for patch management are not paperwork heavy, which can make companies susceptible to leaving systems in known insecure states for longer periods of time. It should be easy to roll out security patched versions of operating systems components, from a reliable vendor, within the scope of a ‘standard change' in ITIL terms - without needing to convene a board or go through rounds of approvals.
Straightforward tools from companies like Snyk can inspect your list of dependencies on external libraries and report on the versions that are found vulnerable to exploit. This static analysis can be done quickly on every commit, for continuous peace of mind. Other automation tools, such as OWASP ZAP and Gauntlt, search for vulnerabilities in running applications as part of an integration test.
Principle of least privilege
Often the weak security link in organisations is the people themselves. Phishing, or fake emails made to trick employees into opening malware or click on links to enter their password details, is a common way for attackers to gain access to sensitive data. Companies should educate both tech and non-tech people on how to identify phishing and what to do if they receive emails they suspect are malicious, and then simulate phishing attacks to see how their staff perform.
Some of these attacks can be mitigated by setting up scanning solutions that rely on technologies like DKIM and SPF, which allow mail clients to try to validate incoming emails and warn users about potential threats - but these are not 100 percent effective. I recommend that companies implement a ‘principle of least privilege' approach to user management, limiting access to systems only to those who need it, and only for the amount of time they need it. If employees can only access systems they absolutely need to do their work, malicious access will be limited as well.
Password management & 2FA
Instead of relying on staff using complicated passwords they can't remember, scribbled down on post-it notes, companies should these days be teaching employees to use a password manager, such as 1Password, to generate and store strong, unique passwords for every service.
The major benefit of password managers is that users only ever need to remember one good password for the password manager itself. 1Password, for example, allows PBKDF2 encrypted password files to be stored locally, synced with the cloud, or shared via something like Dropbox. There's also a feature for teams, which lets certain passwords be shared with different groups of people, following the principle of least privilege.
In addition to this, all staff should use two-factor authentication (2FA) where possible. Usernames and passwords, the first factor of authentication, can be accessed by someone else even when using a password manager. 2FA mobile apps such as Authy, or using a physical hardware token on a key fob, provide an extra layer of security and will help against phishing, for example. The much-publicised 2016 Uber data breach would not have been possible had the company been using 2FA to secure their public cloud accounts at that time.
One thing to think about though is that the US' National Institute of Standards and Technology (NIST) does now no longer recommend using one-time codes sent by SMS, since these can be intercepted - so go with other 2FA options where possible.
In the event of a breach:
If all has failed, and your organisation does end up the victim of a data breach, the best thing is to give an honest and clear explanation of what has been compromised, the impact of the breach and what measures customers should take to prevent further damage. You should also explain what you have done to prevent it happening again. Under GDPR you will have a responsibility to notify the ICO about a breach. Covering up or minimising the issue is never a good idea. Have a protocol for assessing impact and contacting customers, and of course consider that data compromised. By taking proactive steps to increase the security of your sensitive information however, the risks of a breach should be drastically reduced.
Contributed by Jon Topper, CTO at UK DevOps & cloud infrastructure consultancy The Scale Factory.
*Note: The views expressed in this blog are those of the author and do not necessarily reflect the views of SC Media UK or Haymarket Media.