Here's a Nifty Checklist to Secure a Cloud Application

When customers are migrating existing applications from on-premises data centers and from other cloud providers to Oracle Cloud Infrastructure, or even when they are building new cloud native applications on Oracle Cloud Infrastructure, I often get asked for advice on how they can best secure their applications in a cloud environment.

First of all, it is critical that development teams and security teams work in tandem to secure applications as well as the cloud environment. Following the agile methodology, most modern IT organizations have transformed to a DevSecOps model. In fact, Continuous Integration and Continuous Deployment (CI/CD) with on-demand releases has also led to& Continuous Security (CS).

Based on past experience with customer deployments and in training I've done with SANS& and& OWASP, I've put together a nifty checklist that can be used as a guide when securing& any cloud application. This can also be used by your Cloud Security Operations Center (cSOC), should you have one or are looking to establish one.

The checklist is categorized into seven sections:

1. SecOPS and Configuration Management
2. Data Protection
3. Authentication and Access Control
4. I/O Handling
5. Logging
6. Error Handling
7. Session Management

SecOPS and Configuration Management

From the outset, it's important to ensure that all security requirements are documented, and that these requirements are accounted for in your deployment, design, review, testing and change management processes.

Checklist Item

Notes& & & & &

Document security requirements

Work with the cloud Governance, Risk, and Compliance (GRC) group and the application team to document all the security-related requirements. These can be across functional and non-functional requirements. Transforming requirements to user stories allows you to track them using your agile ticketing system (like Rally or Jira).

DevSecOps friendly change management

Automate the change management process and align with the current CI/CD process so that new releases can be deployed only after proper testing and associated documentation.

Automated deployment

Use automation for Continuous Integration and Continuous Deployment to ensure that releases are consistent and repeatable in all environments.

Continuous design review

Continuously review the design and architecture of the application throughout its life cycle. Security analysis, risk identification, and mitigation are key focus areas.

Continuous code review

Continuously review the code of the application as the application is updated or modified.& Security analysis, risk identification, and mitigation are key focus areas.

Continuous security testing

Continuously test the application for security vulnerabilities throughout the DevOps process and the application lifecycle.

Infrastructure hardening based on releases

Harden all components of the logical infrastructure that the application uses as per the guidelines and compliance required for that application environment.

Incident response automation

Automate and continuously update the defined incident-handling plan.

Continuous training

Train developers, cloud engineers, and architects on the new features of the cloud services that the application uses.&

&

Data Protection

It is also important to ensure you have these data protection capabilities. At Oracle, many are built into our cloud infrastructure by default, and others are available as a service.

Checklist Item Notes& & & & & & & & & & & & & & HTTPS only Use HTTPS (TLS) for front end and backend application flows. HTTP access disabled Disable HTTP for all publicly exposed interfaces. Ideally disable it globally. Use vaults for user password stores Use secret management with Oracle wallet or Oracle Key Vault.

Use of Strict-Transport-Security header

Strict-Transport-Security header helps to mitigate any HTTP downgrade attacks using variations of the sslsniff tool. Secure key management Properly store, secure, and rotate keys. Oracle Cloud Infrastructure Key Management can provide this solution. Strong TLS configuration Use TLS 1.2 or above with strong EC cipher strength. Oracle Cloud Infrastructure LBaaS uses TLS 1.2 with following cipher sets: p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 10.5px Helvetica; color: #464646}

ECDHE-RSA-AES256-GCM-SHA384

ECDHE-RSA-AES256-SHA384

ECDHE-RSA-AES128-GCM-SHA256

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 10.5px Helvetica; color: #464646}

ECDHE-RSA-AES128-SHA256

DHE-RSA-AES256-GCM-SHA384

DHE-RSA-AES256-SHA256

DHE-RSA-AES128-GCM-SHA256

DHE-RSA-AES128-SHA256

Reputable certificate authority& Ensure certificates are valid and signed by reputable certificate authorities. Match the name on the certificate with the FQDN of the website.

Browser data caching&

Configure browsers not to cache data using cache control HTTP header or meta tags. Data at rest& In Oracle Cloud Infrastructure, by default, all storage types (block, file, and object) are encrypted. Key exchange Exchange keys over a secure channel. Tokenization of sensitive data Where possible, don't store sensitive data at the web or application layer. If necessary, use tokenization to reduce exposure.&

&

Authentication & Access Control

When it comes to authentication and access control over your cloud infrastructure, I would advise following these guidelines.

Items Notes Access control checks Apply access controls checks consistently all along the stack following the principle of complete mediation. Least privilege Apply the principle of the least privilege by using a mandatory access control systems such as Oracle Identity Cloud Service (IDCS) and Oracle Cloud Infrastructure IAM mediation. Direct object reference Avoid referring to objects directly. Always use relative pointers based on the authenticated user identity and trusted server-side information. Unvalidated redirects Don't permit unvalidated redirects. Put a strong access control policy in place to validate any redirect requests.

Credential security

Avoid hardcoding credentials. Secure the database storing the credentials using multiple tiers of security controls. Strong password policy Implement a strong password policy along with an automated multi-factor identity-based password reset system. Account lockout policy Implement an account lockout policy to protect against brute-force attacks. Display appropriate nonspecific messages around wrong credentials to confuse an attacker. Multi-factor authentication Ensure multi-factor authentication is in place using Yubikeys or other hardware or software-based tokens.

&

I/O Handling

To help ensure secure I/O handling, I recommend reviewing this checklist to mitigate possible security attacks.

Checklist Item Notes Whitelist Use whitelists in place of blacklists. Validate each input or output within the context of use. Standard encoding for the application Use standard encoding like UTF-8 consistently for all the application pages using HTTP headers or meta tags to reduce risks like cross-site scripting attacks. Nosniff header usage X-Content-Type-Options: Use nosniff headers to stop browsers from guessing the data type. Tabnabbing Prevent tabnabbing by denying the linked page the ability to change the opener's tab. This is a common look-a-like phishing attack.& Well formed SQL queries Use parameterized SQL Queries with user content passed into a bind variable to make queries safe against SQL injection attacks. Never build SQL Query strings dynamically from user input. X-Frame-Options Use Content-Security-Policy (CSP) header frame-ancestors directive to mitigate clickjacking. Secure HTTP response header

To defend against MITM and XSS attacks, use X-XSS-Protection, CSP, and Publik-Key-Pin headers.

&

Logging

Of course, logging is a critical part of ensuring adherence to compliance and for maintaining a good security posture. Below are some guidelines on the types of activities to log.

Checklist Item Notes Sensitive data access logging Log sensitive data access to meet regulatory compliance such as PCI and HIPAA. Privilege escalation logging& Log all privilege escalation requests for audit and compliance. Administrative activities using Console,& CLI, and API logging Log all administrative access for application configurations or infrastructure configurations. Authentication and validation activities logging Log all authentication, session management, and input validations. Ignore unimportant data Avoid logging unimportant or inappropriate data to reduce storage and the associated encryption overhead. Secure all logs Securely store logs using encryption and as per the established log retention policy.

&

Error Handling

Below are some best practices for how to handle unexpected errors and the error messages your system sends.

Checklist Item Notes Handle all exceptions Handle unexpected errors and gracefully return to the user or the invoking application. Generic error messages Display generic error messages to the user to protect details of the application stack. Framework generated messages Suppress framework-generated messages because they can reveal sensitive information about the framework used and can lead to sophisticated exploits.

&

Session Management

And finally, I would recommend implementing these session management attributes to avoid any potential security risks.

Checklist Item Notes Session tokens Every time a user authenticates or escalates their privilege level, generate a new session token. Regenerate the token even if the encryption status changes. Idle session timeout& To prevent against Ajax application-based attacks, implement an idle session timeout. Absolute session timeout& To mitigate against a session hijacking, log users out every 4–6 hours. Session destruction In case any tampering or intrusion is detected, immediately destroy the session. Cookie domain path Restrict the domain and the path scope for the application in context. Avoid any wildcard domain setting. Cookie expiration time Set a reasonable expiration time for every session cookie. Cookie attributes Set secure attributes using HttpOnly and secure flags to make the session id invisible to any client-side scripts. Session log out Once the user logs out of their session, invalidate and destroy the session.

&

In conclusion, I hope this checklist will come in handy as you're migrating or building applications in the cloud. I'd also like to cite that this is a subset of various checklists that can be downloaded from the following resource sites:

• NIST
• OWASP
• SANS