As our world becomes increasingly digital, the cloud becomes an equally increasing priority for organizations. By harnessing cloud technology, organizations can do more with less; advanced business intelligence, remote working, internet of things, all of these concepts become a possibility with cloud.
But joining the cloud also opens your enterprise to some level of new risk. That's why all organizations must know the best practices of implementing cloud security to ensure they understand the critical steps, and how they combine to protect your assets.
While implementing a cloud security framework will involve many detailed steps, these are some of the most important:
If your cloud security measures aren't designed to meet your overarching business objectives, quite simply, they won't meet them. This could lead to wasting money on processes that don't benefit your organization, and continued exposure to risks that you haven't adequately mitigated.
Therefore, one of the first steps of any cloud security implementation process must be to identify your core business objectives and drivers - the same as if you were implementing regular security architecture (which we talk more about in Step 3 as well).
Business drivers, identified as part of the Define security architecture phase, are key inputs that help an organization achieve operational and financial results. Whereas your business objectives are carefully thought through goals that sit in the future - something to be achieved - drivers sit in the present, things that must happen now to ensure costs are kept down and revenue high.
Some general business drivers might include protecting your reputation, fighting financial fraud and so on.
But today we're talking specifically about the cloud. So what key inputs will impact costs and revenues with regards to your cloud? Perhaps they are about maintaining operability, protecting customer data, or controlling access levels. No matter what inputs impact your cloud, you must have them written down before you can proceed to the next stages.
Learn to Identify Your Business Drivers and Attributes Here
Look around the market and you'll see a number of cloud implementation workflows available to use, which may also be referred to as frameworks (although, confusingly, 'framework' could also refer to international security standards, such as from the ISO or CSA. Today we're talking about workflows specifically).
Well, the short answer is that they take the guesswork out of improving your cloud security.
Chances are these workflows have been designed by security experts to take into account each possible step in the implementation process, account for who and what must be involved, and offer objectives for each phase. Following these workflows is, essentially, best practice, and can help you achieve optimal results.
Not every expert agrees with each other. So as a customer, how do you choose between frameworks to find one that is actually 'good'? Our advice is to look for two critical factors:
Security architecture is a set of principles, methods and tools to help you translate your business requirements into executable security requirements. This step of the implementation process can build a roadmap of phases to follow that will ensure you have the right people, processes and technology in place to meet the needs of your risk appetite. You're building the 'blueprint' for your organization's security, just like a regular architect would for a house.
● Example: Let's put the security architecture process into a simple analogy: Matko's Pizzeria. Matko's objective is to grow his restaurant revenue. He decides reducing waste is his priority driver, and two of his key business attributes are "Fresh ingredients" and "Consistent quality". After analysing these drivers, he finds out his biggest threat is insect infestation as it is both likely and could have drastic consequences. As a result, he puts together an insect control plan with his employees and enforces it as a new policy. Want more details? Check out our article on implementing security architecture!
Read more: ”Behind the scenes of implementing security architecture”
Security architecture as a whole deals with the entire organization, top to bottom, looking to patch holes and build resistance to security threats no matter where in the company they could become a problem. It can be quite conceptual, dealing a lot with people and processes.
Cloud security architecture is more operational, dealing with the cloud in particular. It drills down into some of the technical requirements of your migration to the cloud, including how apps are communicating, how they're wired together, who is involved and accountable, who has access, and so on.
Yes! Cloud security architecture is also a vital step on a company's road to getting compliant (and being able to prove it). Global security regulations are only getting tighter, and that means organizations must increasingly be able to adhere to shifting standards and provethat all appropriate measures have been taken to minimise their risk of a cyber breach.
When designing your architecture, consider not just questions about tools and software, but also policy. What are the security credentials of your cloud provider? If you're creating your own cloud server, where is it physically located? How is the infrastructure protected? Do you know what to do in the event of a breach? Who owns regulatory compliance in your organization? Do they understand local as well as international (where applicable) regulations?
Read more: "How to respond to a cyber breach"
What is ZeroTrust? It is an additional methodology to consider at this stage of your implementation.
In today's modern world, where internet-connected devices are everywhere, the old firewall approach to security isn't as effective as it once was. No longer can companies simply build and strengthen the perimeter around their assets, because the threat could come from within as well as without.
ZeroTrust replaces the old perimeter-based firewall with a new concept - trust no one. Using this methodology, you will develop strict access controls for users accessing your cloud, whether they are at the office on a work computer, at home on their personal PC, overseas, on their phone, a contractor, permanent staff, new employee, CEO - doesn't matter.
It assumes that security breaches can occur not just from outside actors, but staff as well. Accidents do happen, and the sheer accessibility of the cloud can exacerbate these - particularly when sensitive documents or personal information is at stake.
Getting started with ZeroTrust: Some practical steps
SASE, or Secure Access Server Edge, is a relatively new concept developed by Gartner.
This methodology has been built to remove bottlenecks in traditional corporate cloud migrations, where users are funnelled through a singular company data centre before being on-sent to their destination. While the security of this method can offer a degree of peace of mind to security teams, if too many users try to churn through the bottleneck at one time, it can dramatically slow down their access speeds.
With SASE, security verification takes place prior to accessing the cloud - so the user does not need to go through a data centre to become verified. Their data is encrypted through the SASE gateway, using similar teachings to ZeroTrust.
● Example: For a simple example, let's look again at Matko's Pizzeria. In a traditional approach, customers who wish to order pizza would have to go into Matko's and order at the counter. Later, they could call on the telephone to do the same. Both are secure, but in each case, customers are bottlenecked as there are only so many staff available to man the counter, or so many phone lines. With the principles of SASE, Matko can develop a mobile app or online ordering portal where customers can all order at the same time right from their homes, or their car, or wherever they happen to be. Their details and payment is all verified and secured in the portal, and the order is passed on to the kitchen staff.
SASE is like a cloud add-on, so it requires your organization to have migrated to the cloud already (although you can begin planning for it now, as a part of your architecture plan). You will need to find a SASE vendor, who will ensure that the new access layer is configured correctly for your needs and that you have a management plan in place to maintain it.
RASP, or runtime application security protection, is another optional but recommended security step organizations can take to increase their cost efficiency with regards to security.
Traditionally, when an application held in the cloud comes under attack (or there's a critical security error of another kind), it requires a human to investigate, find the issue and then fix it. This takes time and money, and risks that a critical error may go undiscovered until it is irrevocably compromised.
RASP, meanwhile, is a technology that sits in the cloud environment and lets an app monitor itself, as well as respond to attacks and errors in real-time. RASP programs funnel all communications between the server, user and application to itself, where it can validate requests and ensure they are secure, before sending them on to their destination. RASP also enables an app to scan itself to check for tampering, i.e. automated shared library checksums.
These programs are designed to distinguish between valid use and attacks (like an SQL injection) in real time, taking mitigation measures to thwart such an attack. This could include self shutdown, or blocking communications.
● Putting RASP in our pizzeria example: RASP is all about the system protecting itself, so how would that apply to our simplified pizzeria model? Well, Matko might put a smart thermometer in his pizza oven - if the temperature rises too much (beyond what is safe for his pizzas), this device automatically lowers the oven's power. If this doesn't fix the issue, it alerts kitchen staff to intervene.
In essence, RASP monitors a system, takes small measures to intervene in case of a problem, and if it cannot prevent the issue spreading, it raises the alarm.
Every organization has its threats. If you've already established your risk appetite, chances are you're aware of many of these. Before we can move forward implementing cloud security, you must understand the threats posed to your cloud environment and how you might be able to mitigate them.
Finding your threats
In our security architecture implementation article, we talked about common threats to security architecture. Matko's pizzeria found that its threats were very physical - insects, disasters, electrical failures.
But for cloud security architecture, threats are generally more specific - often related to people. Hackers and other cyber criminals, for example, may try to access your system. Disgruntled staff could become lax in their protocols, or someone could quite simply cause an accident without knowing. At a pizzeria, the equivalent might be robbers, scammers and fraudsters, angry customers, or maybe tired staff making mistakes.
When a business understands its threats, it can put in place mitigation strategies to minimise them - in line with its risk appetite. For cloud security in particular, knowing your threats helps you understand how to configure the cloud, what to train people in, what kind of culture your company must maintain to reduce risks, and so on.
Getting started with threat modelling: Some practical steps
Read more: "Could better security architecture help prevent a major hack?"
You've likely heard of DevOps, but the next evolution is DevSecOps.
Cloud enables faster, more agile development - that's one of its key benefits. But in this faster-paced, flexible environment, there breeds the possibility of increased risk of errors. There may not always be time to strictly check each week's sprint for security errors, leaving these for the security gate towards the end of development.
But, as we know, leaving security until too late can cost a considerable amount of money. To put it in perspective, if an error isn't caught until an app is being published, it increases the cost to fix by as much as 3,000%!
Security can't be a future problem. It's more efficient, not to mention safer, for it to occur in real time, which means integrating security into the CI/CD pipeline. Bring your security teams into the room right from the planning phase, and keep them involved throughout each step of the way. It could significantly cut costs.
Read more: "What is DevSecOps and how is it different to DevOps?"
Getting started with DevSecOps: Some practical steps
By giving careful consideration to the key steps of cloud security implementation, organizations can utilize modern methodologies to protect themselves against potential threats and mitigate the risk associated with misconfiguration.
Taking best practices from security architecture and application security - defining, creating and managing an architecture (from objectives to drivers, attributes, threats and controls), as well as implementing additional measures like ZeroTrust, RASP, DevSecOps, and so on - organizations can guide their migration to the cloud to ensure that each step of the process is designed to meet their unique needs.
While we can sit and explain each step of the cloud security process, we understand that it's another thing entirely to implement it. For most organizations, one of the most effective - and safe - ways to build a cloud security architecture that meets its objectives is to partner with an expert.
And that's where we come in.
We offer free maturity consultations to any organization that is interested in moving securely to the cloud, but isn't sure where to start or how to get there. Our experts will listen to your needs, offer you guidance, and can work with you to tailor a solution that meets your objectives. Contact us today and let's see what we can do for you.