2021 RSA Event Summary Report

Blog Author
Sudarsan Kannan

RSA Conference (RSAC) is one of those few industry events that I look forward to every year where I get to play a humble student, learn from fellow security geeks and also be a thought leader for our customers and partners. The year of 2021 was no different. Having recently set my foot into Uptycs, an innovative cloud native security analytics startup, I wanted to share an outside-in story on RSAC 2021 through our customer's lens.

 

Recently I lost a near and dear within my family who was a friend, a philosopher, a leader to brain tumor at a very young age. This event introduced me to the definition of resilience. Resilience is about how we muster strength amidst failures and losses, raise up and fall less frequently thereafter. Coincidently, this year’s RSAC theme also revolved around resilience.

 

After the recent Solarwinds supply chain attacks, Microsoft Exchange related failures, Colonial pipeline ransomware related losses, business and customers are raising up and actively learning how to maintain business continuity and be more resilient. I’m looking forward to bringing the resiliency learned from personal life in shaping great product futures for Uptycs, and helping customers to be more resilient from such attacks.threat bulletin cta image

 

Here's What I Learned At RSAC This Year

The biggest question I came away from RSAC with was: As a digital first responder how do we get better in cyber resilience during such times, be more vigilant so that we as people and businesses have lesser impact and withstand each impact better?

 

Below are some cyber resilience themes that resonated more than others at this year’s RSAC.

  1. How to build a resilient SOC with XDR evolution
  2. How to make your AI and ML based investments resilient from failures and attacks
  3. How to secure cloud transformation or cloud native initiatives
  4. Why DevSecOps culture is critical for your cloud initiatives to be resilient

 

Key Lessons

1. Make your breadcrumbs tastier – Transforming your SOC

Build a resilient SOC that helps pivot across multiple telemetry sources to detect across attack surfaces and make agile decisions

Attempting to derive contextual information from a deluge of data and tools leads to data anxiety and SOC failure in predicting or stopping attacks, which eventually leads to work fatigue and, finally, attrition. Every alert and data point should be actionable with extended context on what happened before and after. They should help pivot across multiple data sources and tools, and automate specific containment activities based on the alert. Creating the much-needed situational awareness and prioritization out of alert chaos helps preserve working memory of your front line SOC analysts for higher order detection activities such as planning hunt exercises.

 

As your SecOps and SOC teams continue to evolve from using foundational EDR to a next generation XDR it will become easier to improve your operational confidence. Metrics such as handling time per alert per stage, events per analyst per hour, incidents by severity will become more meaningful.

 

Your XDR toolset should help move towards establishing an internal SLA for detection, investigation, and remediation. Attaining those SLA’s requires agility in effective decision making. With at least 30+ tools potentially providing security alerts, pivoting to multiple tools for querying is painful and leads to fragmented workflows. Consolidating on a few platform vendors who can deliver true Machine Learning (ML) and Artificial Intelligence (AI) backed alert prioritization, detection and orchestration workflows will help make your SOC resilient to handle hybrid multi-cloud infrastructure.

 

2. All hail the AI – AI goes mainstream 

Learn how to measure, govern AI and ML tools, and prevent against adversarial AI specific attacks as part of your AI journey

Previous RSACs saw the early emergence of AI use-cases in security. The purpose-built security related AI (“narrow AI”) has evolved into setting a taxonomy for AI risks including vulnerabilities, shared understanding of technical requirements and characteristics, and open-source test beds. As we try to evaluate and adopt AI to complement human decision making in SOCs or other security functions, here are some factors to consider.

 

  1. Use AI for threat hunting, incident response, forensics and or detecting different classes of malware threats (eg: ransomware). Develop multiple campaigns using threat modeling, MITRE attack detections, or Red Canary topmost common threats. Normalize output from endpoint sources such as process injection, event logs, registry, file system, scheduled tasks as a training data set to begin your AI journey.
  2. Do we understand adversarial attack techniques on AI? Specifically making your models address data tampering during AI training phases, evasion techniques such as adding noise during inference stages, replicating behavior for unexpected outcomes and more. Using AI for security objectives is becoming more democratized with several open-source tools such as Adversarial robustness toolbox (ART), Armory etc. Is it time to jump-in?
  3. Biases due to data, people training the models (cognitive and representative bias) and models themselves is still a white space. Transparency of the system in providing reasoning behind the decisions (explainable AI) is critical for adoption. Providing tuning capabilities to address model drifts for unknown datasets is key to competency of the AI system

 

3. The Cloud Menace - Attack on the immutables

Understand and adapt to cloud native attack patterns and complement intrinsic IaaS security capabilities with external toolset

The cloud poses different threats as organizations lift and shift on-prem workloads to cloud type of organizations. Your cloud security maturity model begins with creating visibility and situational awareness across all cloud types. For example, attackers compromise on-premises hosts, establish the trust to gain escalated privileges into cloud accounts. Hence visibility should include your identity posture (eg: credentials in code repositories) on where your user is coming from, including federated 3rd parties. 

Prioritize protecting cloud assets based on most common cloud anti-patterns and cloud threat modeling. Traditional protective or detective controls don’t make the cut in the cloud (eg: antivirus, IPS and IDS or next gen AV) as the workloads are ephemeral and immutable. Building a cloud specific detection stack based on threat models, control plane logs (eg: cloudtrail, cloud logging), service specific logs help analysts to pivot across multiple sources within the cloud or in a hybrid setting (eg: peeking into CMDB or Active Directory).

 

With everything as a code (Infrastructure, policy, security) in the cloud native world, having visibility into code movement across build, deploy and run phases is paramount. Commodity style attacks in the cloud (eg: launching a cloud function to run cryptominer); attacks on the CI and CD pipeline, such as container images or Kubernetes clusters and pods; and network attacks due to peering are real and here to stay. Optimizing through standards such as CIS and SOC2 and NIST, etc... and embedding security within the CI and CD pipeline using a solid IAM governance across all cloud assets provides a great security posture.

 

4. Break down the borders - Shift left together

Embrace, support and enable physics of change between your development and security silos to be a cloud-first organization

Cloud has been an enabler for shifting left by security and developer teams. As an industry we have come a long way in coding securely by integrating code reviews, secure enclaves, using capabilities such as SAST, DAST, SCA into continuous integration and deployment pipeline. But much needs to happen to prevent knowingly introducing unknowns into the code and making the software more resilient to supply chain attacks.

 

With such supply chain attacks (eg: Solarwinds attack), knowing the provenance of the code, visibility into what software is being built securely vs insecurely, establishing least privilege, appropriate way-in blocking builds, and ability to provide exceptions will be paramount in truly shifting to the left [ed note. “shift left” refers to incorporating security earlier in the development process]. The speed of delivering cloud-native features creates more adversarial opportunities to compromise when code comes to life. 

 

As a security practitioner we need to partner with dev and devops, evangelize security, reduce tool related loudness, false positives, and mitigate obnoxious views of those tools among the developer community. In other words, User Defined Security (UDS) is critical to moving left. Developer incentives for scanning images and functions during build phase, scanning container registry for vulnerable images and reducing exposed credentials in code repositories during deploy phase are some examples towards shift left maturity.

 

Wrapping Up

Across all topics that resonated at this year’s RSAC one thread stood out in common: we as digital first responders all struggle in our own way– be it in personal life or in handling supply chain attacks, ransomware attacks, SOC effectiveness, tool fatigue and more. What makes us resilient is sharing struggles, fears, empathy, and helping each other during the time of cyber crisis mode.

 

Want to learn more about how you can secure your cloud attack surface? Click below to check out our new guide.

 

READ THE GUIDE