How do you prepare for common cloud-based security incidents?

By proactively addressing these areas, organizations can better prepare for and mitigate the impact of common cloud-based security incidents: 1. Risk Assessment: Identify potential security risks specific to your cloud environment. 2. Security Policies 3. Training 4. Access Control 5. Regular Audits 6. Incident Response Plan: Develop a comprehensive incident response plan outlining steps to take in the event of a security incident, including escalation procedures and communication protocols. 7. Monitoring: Utilize security monitoring tools (IDS, SIEM, and EDR) to detect and respond to suspicious activity in real-time. 8. Backup and Recovery: Regularly back up data and test recovery procedures to ensure the business continuity.

Assigning a criticality to each asset will enable you to prioritize them and their dependencies. Continuous monitoring will allow you to be alerted of any changes in criticality and re-prioritize.

I always suggest a few steps here to my clients. One of the most important and often overlooked is to create a network diagram that depicts all of your internal & external assets. If you are only using API services this does not exclude you from a diagram. Also, include the communication paths and ports\services each asset uses. Classifying the assets is another great step! Doing this helps inform your asset inventory or vice versa. They both should match up.

Some ways to get started based on my experiences: - Create severity level, categorize which is prioritize of the most important and critical of the assets - Set the indicator for whole services, e.g 50% services down it must be very critical incident - Train and Drill the team to handle the very critical incident with the IR Playbook (not only technical but also People, Process and Technology) - Always Update the BCM (DRP and BCP)

Companies need to understand their environments. Doing an initial security assessment will identify strong areas and gaps. Addressing the gaps will be determined by business needs and feasibility. Not all security solutions require appliances and staff. Shore up your business process and use the native security of your infrastructure first before adding enhancements. From there you can start building incident response on your prioritized data and assets.

One helpful way to define and implement your incident response plan is to not do production work and to deploy your entire environment as code. Using Infrastructure as code (IaC), you can have a unified plan for incident response, business continuity, and disaster recovery. This unified plan always revolves around utilizing your CI/CD pipeline in order to redeploy the entire environment. This does several things. First, it restores service in all those scenarios. Second, it reduces confusion. If your plan is push button redeploy in all scenarios, then you reduce decision fatigue. No matter what, we redeploy. Third, it forces maturity. If you are clicking things in the console then you cannot do push button redeploy.

I dont find the incident management process in cloud environment significantly different with on-prem environment. Start with basics and fundamentals: - Define Incident Response plan, and educate your team with it. Make sure SOD and RACI and Contact points are defined well and there is also a process to keep the contacts updated at all time. - Identify your assets and crown jawless and onboard them to your CMDB o. make sure the CMDB are being updated regularly - have updated vendor support and relevant support contacts - implement continuous compliance monitoring to ensure all technological and process controls are implemented accordingly - Enable and Capture the logs and implement right use cases for operational and security monitoring

Remember that during an incident normal communication channels may become unavailable. It's important to have secondary and even tertiary mode of communication. When all else fails - amateur radio! In all seriousness, you can never have too many fall back plans. A printed and laminated contact card for team members to have contact information available when electronic means are not is essential, as well as a printed handbook or procedures with forms.

NIST SP800-61 guides preparing organizations for computer security incidents, adaptable for the cloud. Key steps for cloud incident response: Craft Cloud-Centric Plan: Define roles, comms for unauthorized access, breaches. Track Cloud Assets: Monitor VMs, containers, databases for quick assessment. Detect Abnormal Activity: Use tools for alerts on user actions, traffic patterns. Triage and Escalation: Set procedures, prioritize, escalate to management. Simulate Tabletop Drills: Refine responses for coordination in breaches, unauthorized access. Legal Reporting: Follow local laws, report incidents to CERT if required, comply with regulations.

I agree with all of the above. I don't feel the communication channels would change much if any especially if this document is updated routinely as part of documentation reviews. The internal and vendor contact information usually will be IT Support of Managers of systems in the event of an incident. More than one medium to contact e.g., phone and email is best.

Drill until you are happy with how it went. You might have to drill more frequently for a while, especially at first. If you want to improve your team's ability to adapt prepare and throw in injects that change the scenario. Afterwards, take time to review and identify what improvements are needed and document those. Don't forget to familiarize them with the cloud lingo and concepts.

IIR Table Top exercises should be coeducated at least once annually depending on the size and complexity of the business. This usually helps identify gaps or inefficiencies in processes. Breach notification requirements are a great idea to include in IR Plans when it comes to HIPAA, etc.

Train your Senior management team as you are training yourself. If they consider the tabletop or a walk-through exercises as an easy tasks, then you have to develop a tailor-made scenarios that will have them lead the organization through real hardship. Also, consider all publicly available scenarios as not good enough and add value to the training with specific development or a scenario closer to the real risks and threats for the organization.

Time to get your hands dirty. Create a show and tell plan for your house so they “know” what is being talked about rather than just reading about it. Trick is: if the band is relatively new, have frequent tabletops to train them. You should expect real results in no sooner than 6 months.

To safeguard against cloud security incidents, implementing robust controls is crucial. Adhering to the shared responsibility model, both the CSP and you play roles in securing the cloud. Key controls include data encryption, IAM, network security, and backup strategies. Logging, auditing, and prompt alerting systems are essential for monitoring and responding to threats. Leveraging CASB and SOAR tools can automate and strengthen these defenses. From my experience, a proactive stance on these measures not only prevents breaches but also prepares you for swift incident response, minimizing potential damage and downtime.

It can be super important to have a separate tenant in the cloud for the purpose of incident response. Imagine your cloud environment being unuseable or contaminated. You don't want to be in the same environment trying to run an incident response. A separate tenant gives you protection from these factors, resilience, and even immutability. This is in addition to your other in-tenant segmentation.

I think this should be step 2 'in this document' rather than 4. After you assess your cloud infrastructure and assign criticality, the security controls should be implemented based on the criticality of the system. One of the best ways to do this is to use NIST 800-53 or a similar framework.

Alright now what ? The team is in-tune with your plan and they know what to do in crisis but in all likelihood, you’d not want to stop and wait for the crisis to unravel. So work out the mantra: prevention is better than cure. Steps: Segregate your workloads into the type of OS/App/Service they hold. Understand your risk exposure around them. Install preventive measures ( follow the Defence in Depth strategy)

The focus is cloud. All of these monitoring tools need to support cloud features or, even better, be cloud native. Major cloud vendors also have resources they can share specific to their platforms. Not all tools are created equal and legacy tools may not and probably won't support cloud scenarios that you will encounter.

All set ! But wait, you’re not considering blocking everything right? Of course not! Next best thing you should have on your list is set up a “centralised monitoring system” wherein you may see all the constitutes of “what’s going on here”. Here’s the time take out the old friend “syslog” out of the dark room and let them stretch out. It’s important to understand just “how much” logging is needed to begin with. This is where most if not all get lost. ( careful ??)

A native SIEM or third party solution will help with monitoring. Also other checks like access reviews, policy reviews, etc. need to conducted routinely.

Feedback is must after an incident gets resolved . This will help organisations to be proactive rather than reactive. Also . Organisations will be in better condition to reduce their attack surface

It's important to predetermine the frequency of review and set reminders so this doesn't go unnoticed. People will join and leave the organization. That means there should also be triggers for updates and more training so those new members are up to speed and team vacancies are filled.

Lessons learnt should not be only added into a knowledge base, but should be socialised and form part of updated learning programmes. These lessons are integral to the effective closure of an incident management process.

What is often not considered is the unique nature of each enterprise. Each organisation has unique processes, intellectual property and human capital that differentiates it from its peers. There is also complex regulatory landscapes that differ between regions and must be considered when developing and testing these plans.