7 Common Cloud Security Pitfalls (And How To Avoid Them)
Introduction
For the final part in this 3 part series (read Part 1 and Part 2) I am looking at the common pitfalls we see organisations falling foul of. This is not an extensive list of everything that goes wrong but are the ones we see that have the biggest negative impact overall.
Pitfalls
Each topic is a blog in of itself but I hope to give you a flavour of each topic. If you are a senior leader in an organisation, whether responsible for security or not, then ask what your organisation is doing about these. If you are responsible for the implementation of security at the application and infrastructure level then ask whether you are falling foul of these pitfalls and whether you are making leadership aware of it.
Ignoring Supply Chain - As organisations we don’t exist alone. We are all part of ecosystems and they always contain suppliers. We need to understand what risk those suppliers, and their services pose to us, as well as understanding how we will cope with failures in the CIA (Confidentially, Integrity & Availability) of their services. Failures of those suppliers should feature in your DR and BCP planning with appropriate testing when required.
Forgetting the Process - It is possible to only consider security in the organisation at the technology level and forget that these individual elements are often linked by processes. A good example of this is account reset processes, which many organisations have found to be the weak link in the chain. When considering the threat landscape make sure you have looked at the overall business logic for your processes to ensure they don’t introduce vulnerabilities. For example, a credit card company had a process which allowed non-authenticated customers to change their address but then used sending new cards and PIN codes to the address as the security control in another process.
Legacy Thinking in Cloud - One of the most common things we see are people trying to shoehorn legacy on-premises security into cloud services. While some controls and processes are valid for the cloud, others are not. It is critical to look at “why” we had those controls previously in terms of the risk they protected against and whether that risk still exists or whether cloud offers new, more appropriate controls. For example, historically we needed to patch the operating system because rebuilding the server from scratch was not an option. Alternatively, in the cloud we can leverage the power to build from new baselined and patched operating systems every day if we choose. The risk is the same unpatched software, but the mitigations may only now be available to us. Cloud is ideally placed to leverage compute power, centralised data storage for log information and automated scale up/scale out/replacement of resources to create an environment to innovate our security. Another challenge is not operating at the same pace changes are happening in your cloud environment. If your application and/or infrastructure is changing on a daily basis then your security needs to be being assessed, modified, and monitored at the same pace otherwise your view of the threat landscape is increasingly out of date (You cannot pentest an application once a year that is modified daily, weekly or fortnightly and expect that test to mitigate risks).
Not Leverage Cloud Services - Similar to the legacy thinking, we see people trying to “roll their own” services. Cloud providers offer vast suites of security related services that many of us could not afford for on-premises environments. Services such as organisation wide guardrails, threat detection, vulnerability detection and automated asset detection give us unprecedented security capability in cost effective ways. Along with security services we have the capability to leverage other services such as load balancing, serverless platforms, object storage, databases, message queues and 100s more. These services are designed to work in highly secure ways while giving flexibility to customers. Obviously these services do have costs associated with AWS managing them for you. However, the alternative is to invest your time/effort to manage the security on your own version, or the riskier approach of running these services without security.
Not Splitting Security Responsibility - This is covered in more detail in the second of this series. The key is that security professionals need to be responsible for setting and managing the guardrails and coaching your teams on the right thing to do. Coupled with developers/engineers actually implementing security controls with the tools available to them at the coalface.
Waiting to Start - Security (particularly if there is a backlog of things to address) can often be put off until we have all the answers. This risk averse process is counterproductive due to the landscape continually changing and as such the longer you wait the more there is to be done. So, have a backlog of things you know that need done, prioritise them, and start doing them. More things will come along, you will learn new things, and things you cannot control will happen. These will feed more items into the backlog and will drive prioritisation decisions. Our security journey is a SatNat journey, we know where we want to get to when we start, but our route will vary as we travel and even the destination may change. If we treat our security journey like a train line we will never start to make tracks. We have seen the evolution of the message from “move fast and don’t worry about breaking things” to “move fast but don’t break things” but maybe it is better to “move fast but don’t break things you can’t fix”.
Automated Testing - The lowest risk change is one you know can’t break anything. If all changes are 100% tested then nothing is a risk. The reality however is that we cannot test for every possible condition 100% of the time. The more we have automated testing in place for our changes the closer we get to zero risk alterations. Concern for the impact of a change is often the single biggest delay for any change as a lack of certainty requires input and approval from multiple parties, including security. If data from automated testing proves that a change has no negative impact on the security of the system then we can evolve and improve at a greater pace.
Conclusion
In conclusion, not all pitfalls can be avoided and as with all things in security there is a balance to be struck between security, feature availability, cost, resource availability, and many other factors. I hope you have found this series thought provoking and helpful, even if you disagree with me. If cloud security is an issue for you at the moment and you want some assistance then please feel free to reach out to us.
Useful Reading
Open Worldwide Application Security Project: An excellent source information on application security. In particular the types of security issues you need to be testing for in your deployment pipelines.
Scottish Government Option Appraisal Template: A little long in the tooth now but one of the few that remains publicly available. Gives a good indication of how choices can be assessed in a balanced way. Shows areas that should be considered in any significant decision with security an element in many of these areas.