Developing a (Cloud) Security strategy
In an increasingly digital world, security has become an important subject for every organization, regardless of its size. With more organizations adopting cloud as their main provider, the need to implement a thorough cloud security strategy has become essential to every business. An ad-hoc security control and response approach is not enough to secure your organization.
But what are the best practices you need to consider, when implementing (cloud) security in you organization? And what are the subjects, you need to be aware of when developing a security strategy?
In a series of blogs, we will show you how we at Luminis address these challenges with our clients and partners.
Why do I need a security strategy?
A well-developed security strategy adds maturity to your organization, helps you detect and prevent threats that accrue now and in the future. It enables organizations to become agile in terms of security and address threats and issues faster. It also helps you prevent overspending on security. When dealing with security, it is important to remember: “Spent the right amount, not more”!
The landscape around (cloud) security changes rapidly. Once your security strategy is developed, you need to regularly review it and follow up on your findings. This is vital for your organization in order to gain maturity in security strategy and keep your workload and data secure.
Some subjects you should consider when developing a cloud strategy:
- Security is the responsibility of the entire organization, not just the security department/team
- It should be proactive and not just a periodic check when a project is pushed to production
- It should be repeatable
- It should be cost effective
- It should minimize risk
- It should be documented
Shared responsibility
When developing a cloud strategy, you first need to be aware of the responsibility you have as a cloud service cust0mer. Alle major cloud service providers apply a “shared responsibility” model. As can be seen in the chart below (AWS shared resposibility model), this differentiation of responsibility is commonly referred to as Security “of” the Cloud versus Security “in” the Cloud.
AWS shared responsibility model
In this model, the cloud provider is responsible for protecting the infrastructure that hosts all of the offered services. Whereas the customer is responsible for securely configuring the cloud services they select.
With this in mind, the next logical step is to map the existing infrastructure and architecture.
Mapping
You cannot secure what you cannot see or do not know! Mapping your existing infrastructure and architecture is a vital part of a healthy and solid (cloud) security strategy. Visualizing your workloads, (key) assets, business objectives, critical information and systems should give you a clear overview of the possible attack surface you need to address, what components are in use, the priorities within your roadmap, how the components are related to each other, what tools you should consider using, etc.
Once you have gathered all this information, it will help you create a balanced roadmap.
Assessment
Once these steps are taken, our suggestion would be to start with an assessment of workloads. This helps you understand the current state of your infrastructure and architecture. This assessment will also contribute to the general security awareness within the organization, which is arguably the most important step in keeping your organization secure.
Policies and compliance
Identifying the necessary mission and business needs, laws, executive orders, guidelines, regulations, policies, standards, guidelines and regulatory compliance for your business helps you understand the current and upcoming challenges. It can serve as a guideline for making the right choices when it comes to choosing a cloud provider, tooling, (security) frameworks and methods.
People, tooling and methodologies
When developing and implementing a security strategy, next to tooling and methodologies, people are equally important! By involving people from your organization, your create ownership and awareness about security. Everybody should be aware of the risks and should be ‘part’ of the general security mindset.
Some of the subjects to consider:
- CIO/CISO
- Well-Architected framework
- DevSecOps
- IaC
- SCA, SAST, DAST
- Encryption (on transit & at rest)
- Zero trust
- OWASP
- Employee education – recurring!
- Backup & DR
Roadmap
Once you have gathered alle the necessary information and documentation, it is good start drawing up a roadmap. This doesn’t have to be in detail. The roadmap is a living document and you should treat it as such.
Think big, start small!
Start with a highover view of the findings from the previous steps, for example on the policy level and then work out the details. Further down the road you start to implement controls, methodologies and tooling.
In the next blog of this security series we will discuss DevSecOps. What are the considerations you need to take into account and what you need to know before applying DevOps methodology for your security?
