As a cloud security architect, I’m often being asked to provide security guidelines for deploying a new environment in the public cloud, a new SaaS solution, or how to connect an on-premise environment to the public cloud.
In this post, I will provide you with some guidelines (for writing guidelines…)
Business requirements
Before writing any security instructions, I get in touch with the business owner of the project, to get an understanding of the business goals – “allow me access to storage”, “allow me to query information from a database”, “allow me to upload files”, etc.
This is crucial before writing any instructions and security requirements.
A good starting point for understanding the business requirements is to review data flow and ask questions such as:
- Which component sends data and which component receives (and perhaps digest) data?
- What data is been stored in the system?
- Are we storing sensitive data such as PII (Personally identifiable information), credit card information, Healthcare data, etc.?
Technical requirements
After understanding the business requirements, I get in touch with the IT team, to get an understanding of the technical goals – “deploy an entire system based on virtual server”, “use micro-service architecture”, “authenticate users against SAML authentication server”, etc.
A good starting point for understanding the technical requirements is to review the architecture diagram of the system components and ask questions, such as:
- Which server sends traffic to which server?
- What (layer7) protocols connect between the system components?
- Is the traffic between components unidirectional or bi-directional?
- How do the end-users authenticate to the system or each of the components?
- How is authorization been managed in the system?
- Is there an audit trail or any type of monitoring capability?
- Is the system going to handle files? (upload / download)
Cloud-related constraints
I always ask myself – what is the cloud service model?
Are we planning to deploy a farm of virtual servers, based on Infrastructure as a Service?
Are we planning to use managed services such as a managed database or managed storage, based on Platform as a Service?
Are we planning to use fully managed services such as Software as a Service?
Knowing the cloud service model will allow me to understand what is my responsibility as a customer of cloud services, what security controls are available for me to use (from anti-malware or patch management on virtual servers to encryption at rest on managed databases, till auditing and user authorization on SaaS applications).
Understand the differences between cloud services capabilities and on-premise capabilities. Few examples:
- Legacy monitoring protocols such as Syslog or SNMP existed for many years on-premise, but modern cloud applications expose API to achieve the same goal.
- Encryption at rest – in the on-premise it was challenging to store and manage encryption keys without HSM (Hardware security module), while most mature cloud providers already have key managed services to achieve this specific goal.
Threat landscape
Before writing security guidelines, I need to understand the threat landscape – what threats is my system facing and what security controls are available for me, whether they are supported by the vendor or whether I need to request adding additional security controls.
Examples:
- For systems that are exposed to the public Internet, there is always the risk of DDoS attacks, so I might need to consider adding an externally managed DDoS protection service.
- For web-based or mobile applications, there is always the risk of application-based attacks – I would review OWASP Top10 to see at least the common web application attacks and try to either guide the developer teams about possible solutions as part of their development process, or in the worst case, instruct to add an external service, from web application firewall, to static code analysis.
- For publicly-facing websites that contain only marketing information, I wouldn’t demand customer authentication and authorization processes for external users (though I would demand authentication and authorization processes for users who need access for a content update or access to maintain the platform itself).
- A data breach is almost always a risk – I need to review the security controls available and decide which control will provide me the most benefits (in terms of security), while still allowing the business to achieve its goals.
Vendor documentation
Never underestimate vendor documentation.
Reviewing the public documentation (or sometimes ask for access to close vendor knowledgebase) and see what capabilities are supported by the operating system, applications deployed above the operating system layer, network layer, database or storage tiers, etc.
Be realistic
The world of information security is full of common best practices that are very well written on paper, but pretty quickly become overhead or unrealistic.
Few examples:
- "Encrypt everything" – Have you ever reviewed the vendor documentation and found out if encryption at transit or encryption at rest is supported by the application or by the platform? Have you ever thought about the process for key rotation and the overhead that comes with it?
- "Log everything" – Have you ever checked if your organization has a central log archive and correlation system? Does your organization have a SIEM system with rules that send only relevant alerts to your SIEM/SOC team?
- "Always authenticate against Active Directory" – Have you checked if your legacy system supports this requirement? Does your legacy system speak Kerberos or perhaps only LDAP protocol? Does your SaaS vendor support Azure AD authentication or is he manage the users and their permissions in a local or proprietary database?
Summary
Writing security guidelines (and especially cloud security guidelines), is an art.
It takes time to gain multidisciplinary knowledge about multiple fields or topics, from the technical side to soft skills such as the business and customer side.
Mistakes are inevitable, but the more we speak to our customers and the more we gain hands-on experience, our security guidelines will get better, in every new document we write.
Top comments (0)