Fingerprinting a Security Team

The central security team in a product development organization plays a vital role in implementing a secure product lifecycle process.  It is the team that drives the central security vision for the organization and works with individual teams on their proactive security needs.   I lead the technical team of proactive security researchers in Adobe. They are all recognized security experts and are able to help the company adapt to the ever changing threat landscape.  Apart from being on top of the latest security issues and potential mitigations that may need to be in place, the security team also faces challenges of constant skill evolution and remaining closely aligned to the business.

This post focuses on the challenges faced by the security team and potential ways to overcome them.

Increase in technologies as a function of time.

A company’s product portfolio is a combination of its existing products, new product launches, and acquisitions intended to help bridge product functionality gaps or expand into new business areas.  Over time, this brings a wide variety of technologies and architectures into the company.  Moreover, the pace of adoption of new technologies is much higher than the pace of retiring older technologies.  Therefore, the central security team needs to keep up with the newer technology stacks and architectures being adopted while also maintaining a manageable state with existing ones. An acquisition can further complicate this due to an influx of new technologies into the development environment in a very short period of time.

Security is not immune to business evolution.

The cloud and mobile space have forced companies to rethink how they should offer products and services to their customers.  Adobe went through a similar transformation from being a company that offers desktop products to one that attempts to strike the right balance between desktop, cloud, and mobile.  A security team needs to also quickly align with such business changes.

Multi-platform comes with a multiplication factor.

When the same product is offered on multiple operating systems, on multiple form factors (such as mobile and desktop), or deployed on multiple infrastructures, security considerations can increase due to the unique qualities of each platform. The central security team needs to be aware of and fluent in these considerations to provide effective proactive advice.

Subject matter expertise has limitations.

Strong subject matter expertise helps security teams’ credibility in imparting sound security advice to teams.  For security sensitive areas, experts in the team are essential to providing much deeper advice.  That said, any one individual cannot be an expert on every security topic.  Expertise is something that needs to be uniformly distributed through a team.

These challenges can be addressed by growing the team organically and through hiring.  Hiring to acquire new skills alone is not the best strategy – the skills required today will soon be outdated tomorrow.  A security team therefore needs to adopt strategies that allow it to constantly evolve and stay current. A few such strategies are discussed below.

T-Shaped skills.

Security researchers in a security team should aim for a T-Shaped skill set.  This allows for a fine balance between breadth and depth in security. The breadth is useful to help cover baseline security reviews.  The depth helps researchers become specific security subject matter experts. Having many subject experts strengthens the overall team’s skills because other team members learn from them and they are also available to provide guidance when there is a requirement in their area of expertise.

Strong Computer Science foundations.

Product security is an extension of engineering work.  Security requires understanding good design patterns, architecture, code, testing strategies, etc. Writing good software requires strong foundations in computer science irrespective of the layer of technology stack one ends up working on. Strong computer science skills can also help make security skills language and platform agnostic.  With strong computer science skills, a security researcher can learn new security concepts once and then apply to different platforms as and when needed.  With such strong fundamentals, the cost of finding out the “how” on new platforms is relatively small.

Hire for your gaps but also focus on ability to learn quickly.

A working product has so many pieces & processes that make it work.  If you can make a mental image of what it takes to make software, you can more clearly see strengths and weaknesses in your security team.  For example, engineering a service requires a good understanding of code (and the languages of choice), frameworks, technology stacks (such as queues, web server, backend database, third party libraries), infrastructure used for deploying, TLS configurations, testing methodologies, the source control system, the overall design and architecture, the REST interface, interconnection with various other services, the tool chain involved – the list is extensive. When hiring, one facet to evaluate in a candidate is whether he or she brings security strengths to the team through passion and past job experience that can fill the team’s existing gaps.  However, it can be even more important to evaluate the candidate’s willingness to learn new skills.  The ability to learn, adapt, and not be held captive to one existing skill set is an important factor to look for in candidates during hiring.  The secondary goal is to add a variety of security skills to the team and try to avoid duplicating the existing the skill set already in the team.

“Skate where the puck’s going, not where it’s been.”

To stay current with the business needs and where engineering teams are headed, it is important for a security team to spend a portion of their time investigating the security implications of newer technologies being adopted by the product teams.  As Wayne Gretzky famously said, “you want to skate where the puck’s going, not where it’s been.” However, security teams need to cover larger ground. You do have to stay current with new technologies being adopted. Older technologies still get used in the company as only some teams may move away from them. So it would be wise not to ignore those older technologies by maintaining expertise in those areas, while aiming to move teams away from those technologies as they become more difficult to effectively secure.  Predicting future areas of investment is difficult.  Security teams can make that task easier by looking at the industry trends and by talking to engineering teams to find out where are they headed.  The managers of a security team also have a responsibility to stay informed about new technologies, as well as future directions their respective companies may go in, in order to invest in newer areas to grow the team.

Go with the flow.

If a business has taken a decision to invest in cloud or mobile or change the way it does business, a security team should be among the first in the company to detect this change and make plans to adapt early.  If the business moves in a certain direction and the security team does not, it can unfortunately label a team as being one that only knows the older technology stack.  Moreover, it is vital for the security team to show alignment with a changing business. It is primarily the responsibility of the security team’s leadership to detect such changes and start planning for them early.

Automate and create time.

If a task is performed multiple times, the security team should evaluate if the task can be automated or if a tool can do it more efficiently.  The time reduced through automation and tooling can help free up time and resources which can then be used to invest in newer areas that are a priority for the security team.

Growing a security team can have many underlying challenges that are not always obvious to an external observer.  The industry’s primary focus is on the new threat landscapes being faced by the business.  A healthy mix of organic growth and hiring will help a security team adapt and evolve continuously to the changes being introduced by factors not in their direct control.  It is the responsibility of both security researchers and the management team to keep learning and to spend time detecting any undercurrents of change in the security space.

Mohit Kalra
Sr. Manager, Secure Software Engineering

A Vendor Perspective on Crowd Sourced Penetration Tests

Bug bounties, also known as crowd sourced penetration tests, are becoming increasingly popular. New programs are announced every month. At NullCon this year, there was an entire track dedicated to the topic where vendors and researchers could meet. For a security researcher, there are a ton of options for participating ranging from the self-run programs, such as Google’s, to participating on consolidated platforms like BugCrowd and HackerOne. However, for the vendor, the path into bug bounties can be somewhat complex and the most significant benefits are not always obvious. Here are some tips on how to get more from your bug bounty.

Preparation

You should pick a team that has gone through several traditional penetration tests and where the ROI from those tests is trending down. If traditional consultants are still finding numerous bugs and architectural issues, your time and money would be better spent addressing the known issues and strengthening the architecture. Testing against a more mature development team can also benefit in other ways as you will soon see. A good crowd-sourced penetration test will involve both sides, researchers and development teams, being active in the bounty program.

If you have never done a bounty before, starting with short-term, private bounties will allow you to experience a few hiccups in a controlled situation. Be sure that you have planned out how to issue accounts to a large number of users and that the environment works when testing from outside your corporate environment. Try testing from home just to make sure it works.

Bounty guidelines

The large number of public bounties can serve as a baseline template for your test rules. As you review them, be sure to take note of their differences and consider what may have lead to those differences. A good set of bounty rules will be tailored to the service being tested. One of the less obvious components of a bounty announcement is how you describe your service to the tester. While the service may be extremely popular within your social circles, a researcher across the globe may have never heard of it. Therefore, be sure your bounty description provides an easy-to-understand description of what they are testing and perhaps a link to a short YouTube video that has your product pitch. The less time a researcher has to spend figuring out the goal of the service, the more time they can spend finding quality bugs.

Thematic issues

Penetration tests are typically scoped to a certain set of new features. However, crowd sourced penetration tests are often scoped across the entire service. Since traditional penetration tests are often focused on specific areas, they will not find issues in the connective code between features. Also, since the researchers are testing across the entire service, they are testing across the entire development team and not just within individual sprint teams. This may allow you to pick up on things that the overall team is consistently missing which can guide you as to where to focus energy going forward. For instance, if you have several authorization bugs, then is there a way to better consolidate authorization checking within the platform or is there a way to enable the quality team to better test these issues?

Critical bugs

Since the bounty hunters usually want to get top dollar for their efforts, they will often find more critical bugs. A critical bug is often the result of multiple issues that aren’t mentioned in the initial write-up. For instance, if they send you your password file, then there should be multiple questions beyond what type of injection was used in the attack. A few examples: Would egress filters on the network help? Do we need host monitoring solution to detect when the server process touches unexpected files? It is important to remember that these critical bugs aren’t just theoretical issues found through a code review. These vulnerabilities were successfully exploited issues found via black box testing of your infrastructure from a remote location.

Variant testing

If you have developers on hand during the bounty, then the developers can push the patch to the staging environment before the end of the program. You can then reach out to researcher and say, “Bet you can’t do that twice!”  You basically offer the researcher a separate bounty if they can find a variant or the same bug in a different API. It often isn’t difficult for the researcher to re-test something they have already tested. For the developer, they can get immediate feedback on the patch while the issue is still fresh in their minds. In my experiments at Adobe, losing that bet with the researcher is more valuable than the money it costs us because it typically identifies some broader issue with the platform or the process. This can be key for critical bugs.

Red Team/Blue Team

With a crowd sourced penetration test, you are likely testing against your staging environment or a dedicated server in order to minimize risk to your production network. A staging environment typically has low traffic volumes since only the product team is using it. However, during the testing period, you will have people from across the globe testing that environment and reporting the vulnerabilities that they are finding. For your response teams, this is an excellent opportunity to see what your logs captured about the attack. In theory, identifying the attack should be straight forward since the staging environment is low volume, you know what attack occurred, and you have a rough estimate of when the attack occurred. If you can’t find an attack in your logs under those conditions, then that is clear feedback about how your logging and monitoring can be improved. If you can save the logs until after the bounty has ended, this type of analysis can be done post-assessment if you don’t have the resources to play along real time.

A crowd-sourced penetration test can change up the routine you have established for finding issues. Like any change in routine, there can be a few challenges at first. However, when done well, they can provide a vendor with insights that they may have never obtained through the existing status quo. These are not a replacement for traditional consultants. Rather, the new insights into the platform can help you re-focus the consultants more effectively to get a higher ROI.

 

Peleus Uhley
Principal Scientist

Reflections on Pwn2Own

Returning from CanSecWest left me reflecting on how the Pwn2Own competition has evolved over time. A lot has changed in the Pwn2Own competition over the years. The event has grown in attendance, competitors, and complexity, just as the industry has grown.

For the first contest in 2007, no one competed on the first day. Shane McCauley called fellow security researcher Dino Dai Zovi in NYC that night and urged him to compete. Dino was able to write the exploit over night and win the contest on the second day. Visually, the attacks seem no different from year to year. The contestant sits down at the machine, and “seconds” later the calculator (or notepad in this year’s case), pops up on the screen.  However, the preparation for the attacks from 2007 to 2016 are now drastically different, with contestants preparing attacks weeks in advance.

Media coverage around security advisories is often just a run down of how many CVEs a vendor released that month. People often imply from these articles that all the CVEs are easily exploitable and trivially weaponizable. This can lead to false perceptions that exploiting the software is a simple task. In reality, a CVE from a vendor is not a guarantee of exploitability. Even if the CVE can give the attacker the ability to overwrite memory, that is not a guarantee that it can be weaponized. Technologies such as ASLR (Address Space Layout Randomization) weren’t even released for Mac OS X when Dai Zovi competed in 2007. Today’s attackers have to work around defenses such as CFG (Control Flow Guard), Isolated Heaps, and a number of other technologies designed to prevent a crash from becoming an exploit.

In addition, competitors have to deal with the fact that the contest frequently occurs after Patch Tuesday where a vendor’s security improvements could interfere with their attack. Adobe has been aggressively adding mitigations to Flash Player over the last few months. In our release the week before the contest, we added changes to zero memory more often and leveraged the Windows’ low fragmentation heap. Both Adobe and Google found that some of the contestant’s entries overlapped with recent security reports. Part of the reason for the increasing payouts for the winners comes from the fact that the targets for the competition all have active security teams and external communities that are constantly working to improve the platform. As the community and vendors continue to mature their software, bug or mitigation collisions become more of a material risk for competitors. While it may not seem like it on the surface, the attackers are trying to hit moving targets.

The Flash Player updates prior to the contest led to some failed attempts at the competition. The failed attempts were by teams who had already won under different categories. Therefore, the competitors were clearly highly skilled and had already proven themselves to be capable of weaponizing exploits for the target platform. The reality is that what they are attempting to do is not easy and the failures serve to remind us how hard it is to get those wins. When any competition gets to a certain level, even the most skilled players are going to experience some losses.

That said, the contest always has its share of winners. Those wins demonstrate that there is always more that vendors can do in order to improve security. While the individual bugs help, Pwn2Own is truly valuable because it shows how different researchers will try to bypass the existing mitigations to create the fully weaponized exploit. That insight into different attack approaches inspires us as vendors to come up with the next generation of defenses.

Like many pros, the winning contestants always make it look easy. Although, as an industry we are often too quick to lump everything in the same “it is easy because it is completely vulnerable” bucket. Companies like Adobe, Microsoft, and Google are in a constant sprint with attackers. The security industry has progressed from the days of just trying to write clean, well validated code. Today, we are adding in large platform features that serve no other purpose than trying to thwart attackers. These types of features are added at an increasingly frequent basis. The companies who are on the front line of this battle will change and grow over time. It is important for those vying to one day be on the defender’s side of Pwn2Own to understand the current table stakes.

Overall, Pwn2Own is a fun contest to interact with security researchers and to push the industry forward. Beneath the high level pageantry of smoking jackets and large prizes, is a low-level escalation between offensive and defensive strategists. While the visual results from watching in the room seem similar from year to year, the innovation and challenge required to achieve those results increases every year.

Peleus Uhley
Principal Scientist

Adobe @ Women in Cybersecurity 2016

Adobe was a supporter of the Women in Cybersecurity (WiCys) conference again this year. This year’s conference was organized by Tennessee Tech and held in Dallas, Texas. We had a great experience over the three days of the conference which saw women from across industry and academia come together to discuss important security topics and encourage more women to pursue careers in security. Adobe was joined by several major industry peers including Google, Facebook, Cisco, and IBM.

The conference provided a good mix of technical and non-technical sessions. First off was a keynote by Heather Adkins, Director of Information Security at Google. She talked a little bit about how she became the first woman hired in an operational role at Google and also the first woman on Google’s corporate security team. She then discussed her ideas for structuring an incident response organization. Key components of a good incident response organization per Ms. Adkins are: 1) Figure out what happened (forensics), 2) Are we still under attack (Monitoring), 3) Who did it (Threat intelligence), and 4) Restoring the business (Remediation). It was helpful to hear how another large peer organization like Google handles incident response.

One of the workshop sessions we found most interesting was on the topic of “Big Data Analytics for Cyber Security Applications.” It discussed how to leverage big data frameworks in the field of cyber security. The workshop taught us how to create smaller data sets from the huge amount of threat intelligence information received nowadays and process the data sets using tools such a Hadoop or Spark. It also described the varying levels of sanitization and risk associated with using different malware data sets. Data sets in academia are highly sanitized, and low risk, but typically out-of-date. Research data sets are moderately sanitized and have moderate risk associated with download, but are more current. Individual malware collections are the least sanitized, and have the most risk associated with download, but are up-to-date. Adversaries are thus actively modifying their patterns of behavior to avoid detection (polymorphism) – so multiple techniques and tools are needed to adapt our defenses.

We particularly enjoyed the non-technical sessions that included women leaders in the industry talking about their career journey and how they got to where they are today. Particularly impressive was the talk by Shelley Westman, VP of Operations and Strategic Initiatives, from IBM. Shelley talked about the various stages of her career and experiences as a woman at each of those stages. Shelley also discussed the importance of building relationships with male allies who will support opportunities for women in the workplace.

The conference also had some great networking opportunities during the social events hosted by several companies. We got a chance to attend one hosted by Facebook and participate in a “lean-in” circle conversation. We also attended the Cisco event where we had great interactions with their security team and got to learn more about their security and trust organization.

It was a great conference again this year and we’re happy that Adobe continues to support organizations working to make more opportunities available for women in our industry.

Disha Agarwal
Product Security Manager

Jeanette Azevedo
Security Engagement Specialist

Observations on CanSecWest 2016

Several members of Adobe’s product security team attended CanSecWest this year. The technical depth and breadth of the research presented in Vancouver this year yet again lived up to expectations.  Of the security conferences that Adobe sponsors throughout the year, CanSecWest consistently draws a critical mass from the security research community, with offensive, defensive and vendor communities well-represented.  Research presented this year ranged from discussions about advanced persistent threats (APTs), to vulnerabilities in software, to frameworks that assist in hardware security testing.

Trending Topics

Securing “the cloud” and the underlying virtualization technology is increasingly recognized as a core competency rather than an add-on.  A presentation by Qinghao Tang from Qihoo 360 demonstrated several security testing techniques for virtualization technology.  In particular, his work outlined a framework for fuzzing virtualization software which lead to the discovery of four critical vulnerabilities in QEMU emulator.

In a separate presentation, Shengping Wang (also from Qihoo 360) described a technique to escape a Docker container and run arbitrary code on the host system.  Specifically, the technique allowed an attacker to tamper with data structures storing kernel process descriptors to yield root access.

As the Internet of Things (IoT) continues along its explosive growth path, the community assembled at CanSecWest is among the more vocal warning of the security implications of billions of inter-connected devices.  Artem Chaykin of Positive Technologies described how almost every Android messaging app that uses Android Wear is vulnerable to message interception.  Moreover, malicious third party apps can be used to not only intercept messages, but also send arbitrary messages to everyone on the contact list of a device.

A separate talk by Song Li of OXID LLC described attacks on “smart” locks.  The attacks exploit pairing between a dedicated app and a bluetooth key-fob to achieve DoS (i.e., inability to unlock the door) and unintended unlocking.

Attributing cyber intrusions to specific actors or APTs can be controversial and subject to error.  This was the topic of an interesting talk by several researchers from Kaspersky Labs.  In particular, APTs have increased their use of deception tactics to confuse investigators attempting to assign attribution, and Kaspersky highlighted several examples of APTs deliberately planting misleading attributes in malware.

Continuing with the APT theme, Gadi Evron of Cymmetria discussed how the OPSEC of APTs have evolved over time to handle public disclosure of their activities.

Additional research

Building on recent advances in static and dynamic program analysis, Sophia D’Antoine of Trail of Bits described a practical technique for automated exploit generation.  The techniques described have inherent scalability issues, but we expect to see increased automation of certain aspects of exploit development.

In an exploration of graphics driver code, the Keen Labs Tencent team described fuzzing and code auditing strategies to identify bugs in Apple’s graphics drivers. Moreover, the team described an interesting method to gain reliable exploitation of a race condition that caused a double-free vulnerability on a doubly-linked list representation.

Guang Tang of Qihoo 360’s Marvel Team demonstrated how to exploit a vulnerability in the J8 javascript engine on a Google Nexus device to achieve remote code execution.  With code execution achieved, his team was then able to perform device actions such as installing arbitrary apps from the app store.  Importantly, they demonstrated that this vulnerability is still present in the Android PAC (Proxy Auto Config) service.

Finally, building on earlier work by Google Project Zero and other research, Chuanda Ding from Tencent Xuandu Lab presented research on abusing flaws in anti-virus software as a means to escape application sandboxes.

The exposure to bleeding edge research presented by subject matter security experts, and the opportunity to forge new relationships with the security research community sets CanSecWest apart from the security conferences Adobe attends throughout the year.  We hope to see you there next year.

Slides for these and other CanSecWest 2016 presentations should be posted on the CanSecWest site in a week or two.

Pieter Ockers
Sr. Security Program Manager

FedScoop Sits Down with our own Mike Mellor to Talk About Adobe’s Security Practices 

Adobe recently hosted the 7th annual Adobe Digital Government Assembly in Washington, DC. Our own Mike Mellor, Director of Security for Adobe Marketing Cloud, sat down for an interview with FedScoop online magazine to discuss Adobe’s core security initiatives and best practices. In this 2 minute interview, Mike talks about the Adobe Secure Product Lifecycle (SPLC) and other activities we use to help ensure secure application development practices. In addition, he talks about how we are working at the infrastructure and platform layer to meet industry security and privacy standards through the Adobe Common Control Framework (CCF). Finally, he discusses how we decide our major areas of focus for security to help meet our customers’ risk management needs.

You can watch the entire interview below:

Adobe Security Team Members Win Recent CTF Competition

Kriti and Abhiruchi from our corporate security team in Noida, India, were crowned the winners of the recent Winja Capture the Flag (CTF) competition hosted at the NullCon Goa security conference. Twelve (12) teams competed in this year’s contest. We would like to congratulate Kriti and Abhiruchi on their win. Adobe is an ongoing sponsor of the Nullcon conference. This competition was created by women to encourage their peers to enter the field of cybersecurity. It is a complete set of simulated web application security hacking challenges. Each challenge is separated into small tasks that can be solved individually by the competitors on each team. Each team works through the timed two (2) hour duration of the event in an attempt to attack and defend the computers and networks using prescribed tools and network structures.

Adobe is a proud supporter of events and activities encouraging women to pursue careers in cybersecurity. We are also sponsoring the upcoming Women in Cybersecurity conference March 31st to April 2nd in Dallas, Texas. Members of our security team will be there at the conference. If you are attending, please take the time to meet and network with them.

David Lenoe
Director, Product Security

New Security Framework for Amazon Web Services Released

The Center for Internet Security, of which Adobe is a corporate supporter, recently released their “Amazon Web Services Foundations Benchmark.” This document provides prescriptive guidance for configuring security options for a subset of Amazon Web Services with an emphasis on foundational, testable, and architecture agnostic settings. It is designed to provide baseline suggestions for ensuring more secure deployments of applications that utilize Amazon Web Services. Our own Cindy Spiess, web security researcher for our cloud services, is a contributor to the current version of this framework. Adobe is a major user of Amazon Web Services and efforts like this further our goals of educating the broader community on security best practices. You can download the framework document directly from the Center for Internet Security.

Liz McQuarrie
Principal Scientist & Director, Cloud Security Operations

RSA Conference 2016 Is Just Around the Corner 

It is that time of year again. The world’s largest security conference is descending on San Francisco next week, February 28th – March 4th. This year, myself and members of my team will be participating in the Executive Security Action Forum (ESAF) and speaking during track sessions of the main conference.

First up will be Mike Mellor, our Director of Security for Marketing Cloud, speaking on, “Security Monitoring in the Real World with Petabytes of Data.” This session will discuss how we use intelligent security monitoring to help safeguard our customers’ data. His session starts at 2:20 p.m. on Tuesday, March 1st, in the “Sponsor Special Topics” track in room North 131.

Later in the week will be Peleus Uhley, our Lead Security Strategist, speaking on, “Techniques for Security Scalability.” His session will discuss proper strategies and solutions for implementing security “at scale” in large organizations with diverse technology stacks. His session starts at 9:00 a.m. on Friday, March 4th, in the “Security Strategy” track in room West 3004.

As always, members of our security teams and myself will be attending the conference to network, learn about the latest trends in the security industry, and share our knowledge. Looking forward to seeing you.

Brad Arkin
Chief Security Officer

Marketing Cloud Gains New Compliance Wins

Over the past couple of years, we have developed the Adobe Common Controls Framework (CCF), enabling our cloud products, services, platforms and operations to achieve compliance with various security certifications, standards, and regulations (SOC2, ISO, PCI, HIPAA, FedRAMP etc.).  The CCF is a cornerstone of our company-wide security strategy. The framework has gained acceptance and visibility across our businesses leading to a growing roster of certifications.

Last week, Adobe Marketing Cloud became compliant with SOC2 -Type 1. This certification also enables our financial institution customers to comply with the Gramm-Leach Bliley Act (GLBA) requirements for using service providers.

In addition to SOC2 – Type 1, Adobe Experience Manager Managed Services (AEM MS) and Adobe Connect Managed Services (AC MS) have achieved compliance with ISO27001.  AEM MS has also achieved compliance with HIPAA, now joining AC MS in this designation.  This is in addition to the recently confirmed FedRAMP certification for both of these solutions, achieved in 2015.

During 2015, the Document Cloud eSign service implemented the CCF as well and became compliant with SOC2-Type 2, ISO27001, PCI, and HIPAA requirements. Please refer to the “Adobe Security and Privacy Certifications” white paper on Adobe.com for the most up-to-date information about our certifications across our products and services.

Over the past 3 years, we have made significant investments across the company to harmonize various security functions, compliance and governance processes, and technologies. These are major accomplishments and milestones for Adobe’s cloud services and products which will allow us to provide our customers with assurance that their data and applications are more secure.

We have also been out in the security and compliance community, talking with information security and compliance professionals about CCF. This has enabled further collaboration with industry peers in this area. This is a all part of our on-going commitment to help protect our customers and their data. We will update you in future posts on this blog as we achieve additional compliance milestones.

Abhi Pandit
Sr. Director – Risk Advisory and Assurance