Erwin Karincic of Virginia Commonwealth University selected to carry on Tipton’s legacy in information security
Clearwater, FL – January 5, 2017 –(ISC)²® today announced that Erwin Karincic, undergraduate student at Virginia Commonwealth University (VCU), is the recipient of its 2016 Harold F. Tipton Memorial Scholarship. The Tipton Scholar is selected annually from among the previous years’ recipients of the (ISC)² Undergraduate Scholarships.
The (ISC)² Harold F. Tipton Memorial Scholarship, administered by the Center for Cyber Safety and Education™, was introduced in 2012 to provide enthusiastic and aspiring university students pursuing cyber, information, software and infrastructure security degrees, with a pathway into the profession. The scholarship was named after the late information security industry pioneer and (ISC)² co-founder Harold F. Tipton, and was established through the support of (ISC)² members, and CRC Press and their Taylor & Francis Group. Often referred to as “the grandfather” of the Certified Information Systems Security Professional (CISSP®), Hal’s work with (ISC)² as its past president, chief instructor and ambassador was integral to the formation of (ISC)² and the information security profession.
In 2016, the Center awarded scholarships to 44 students worldwide. The undergraduate recipients were invited to apply for the Harold F. Tipton Memorial Scholarship.
“It is a great honor for me to be named the Harold F. Tipton Scholar for 2016,” said Erwin Karincic. “This award is the most prestigious in the cybersecurity profession, and I am really proud to be the recipient. I will be sure that it is used to its full potential throughout my studies and my career.”
Mr. Karincic’s passion for technology started when he was only seven years old, growing up in Bosnia. His computer broke and without anyone to fix it, Karincic bought a hard drive and operating system, then figured out how to fix it himself. Immigrating to the United States in 2014, he learned English and began excelling academically, enrolling in college-level courses as a high school student. He is currently studying computer engineering at VCU and plans to pursue a career in cybersecurity.
“It’s quite impressive that Mr. Karincic is a 4.0+ student, has already earned more than nine professional IT certifications, and has competed in several cybersecurity competitions,” said Patrick Craven, director of the Center for Cyber Safety and Education. “He aspires to earn the CISSP and to help mentor other students, which demonstrates his motivation to excel as a leader in the industry. We’re pleased to honor him with this memorial scholarship to help carry on the late Hal Tipton’s legacy.”
Undergraduate, graduate and post-graduate students all have the opportunity to build careers in the field of information security through the (ISC)² Information Security Scholarship Program. The scholarship application period for 2017 opened on January 1st with the Women’s Scholarships. The application period for Undergraduate Scholarships opens on February 15th, and on February 28th for Graduate Scholarships.
(ISC)² is an international nonprofit membership association focused on inspiring a safe and secure cyber world. Best known for the acclaimed Certified Information Systems Security Professional (CISSP) certification, (ISC)² offers a portfolio of credentials that are part of a holistic, programmatic approach to security. Our membership, over 123,000 strong, is made up of certified cyber, information, software and infrastructure security professionals who are making a difference and helping to advance the industry. Our vision is supported by our commitment to educate and reach the public through our charitable foundation– The Center for Cyber Safety and Education. For more information on (ISC)², visit www.isc2.org, follow us on Twitter or connect with us on Facebook.
The Center for Cyber Safety and Education (the Center), formerly the (ISC)² Foundation, is a nonprofit charitable trust committed to making the cyber world a safer place for everyone. The Center works to ensure that people across the globe have a positive and safe experience online through their educational programs, scholarships and research. Visit www.iamcybersafe.org.
Media Contact
Maria Forrest
Senior Manager of Corporate Communications mforrest@isc2.org
727-201-5759
The DragonOK group has been actively launching attacks for years. We first discussed them in April 2015 when we witnessed them targeting a number of organizations in Japan. In recent months, Unit 42 has observed a number of attacks that we attribute to this group. Multiple new variants of the previously discussed sysget malware family have been observed in use by DragonOK. Sysget malware was delivered both directly via phishing emails, as well as in Rich Text Format (RTF) documents exploiting the CVE-2015-1641 vulnerability (patched in MS15-033) that in turn leveraged a very unique shellcode. Additionally, we have observed instances of the IsSpace and TidePool malware families being delivered via the same techniques. While Japan is still the most heavily targeted geographic region by this particular actor, we also observed instances where individuals or organizations in Taiwan, Tibet, and Russia also may have been targeted.
Infiltration
We observed two unique techniques of infiltration for this particular campaign:
Phishing emails being sent with malicious executables directly attached
These emails targeted the following industries in Japan:
Manufacturing
Higher Education
Energy
Technology
Semiconductor
The malicious RTF files in question leverage a very specific shellcode to drop and execute the malicious payload, as well as a decoy document. Decoy documents are legitimate benign documents that are opened after the malicious payload is delivered, thus ensuring that the victim does not become suspicious because their expected document opened as expected.
Two samples were found to include the decoy document show in Figure 1.
The title of the document roughly translates to “Ministry of Communications & Departments Authorities Empty Sites and Hosted Public Works Source Clearance Photos”. The use of traditional Chinese indicators the target likely residing in either Taiwan, Hong Kong, or Macau. However, based on the Taiwanese subject matter in this document, we can safely come to the conclusion that the intended victim was of Taiwanese origin. These samples delivered an updated version of the IsSpace malware family, which was discussed previously in a watering hole attack targeting an aerospace firm. IsSpace is an evolved variant of the NFlog backdoor, which has been used by DragonOK in the past.
Figure 1 Taiwanese decoy document
Two other samples were identified that used a Tibet-themed decoy document. The document in question (Figure 2) appears to be an internal newsletter from the Central Tibetan Ministry, as suggested by the logo used as well as the content of the document itself. This document indicates that the malware may have been targeted towards an individual that is interested in Tibetan affairs. These particular samples were unique in that they delivered the TidePool malware family that we reported on in May of 2016. We have not previously observed DragonOK using TidePool in attacks.
We also identified an additional sample using decoy targeting Taiwanese victims (Figure 3), which deployed a newer sysget sample.
Figure 3 Taiwanese-targeted decoy document
Other new samples associated with this group used a Russian language decoy document (Figure 4.) The decoy document in question discusses the GOST block cipher, which was created by the Russian government in the 1970’s. The combination of Russian language and Russian-specific subject matter indicates that the intended victim speaks Russian and may be interested in encryption. Like the previously discussed Tibetan decoy documents, these samples also delivered the TidePool malware family.
Figure 4 Russian decoy document discussing the GOST block cipher
Finally, multiple samples used a traditional Chinese language decoy document that discussed a subsidy welfare adjustment program. The use of traditional Chinese indicators the target likely residing in either Taiwan, Hong Kong, or Macau. Similar to other attacks witnessed, a variant of the sysget malware family is installed by these files.
Figure 5 Decoy document discussing subsidy welfare adjustment program
Malware Deployed
In looking at the various malware samples used in attempted attacks, the following four families were identified:
Sysget version 2
Sysget version 3
TidePool
IsSpace
We broke the sysget classification into multiple variants when we found that a number of changes have been made since our April 2015 report. Major distinctions between the versions of sysget include the following:
Sysget version 2
Removed support for persistence on Windows XP
Reworked the URIs used for network communication
Added additional layers of encryption for network communication and stored configuration files
Switched from RC4 to AES-128
Sysget version 3
Numerous anti-debug and anti-vm procedures added
Encrypted URIs in network communication with an initial static key
In addition, we observed a sysget version 4 that was discovered in another sample during our research. This version is not attributed to a specific attack against an organization.
Indicators of compromise related to sysget version 4 and other samples not directly attributed to specific attacks may be found in the Appendix of this blog post. Additionally, more information about the various sysget variants may also be found in the Appendix.
The TidePool samples encountered are consistent with the samples previously discussed. I encourage readers to view our previous blog post to learn more about the intricacies of this particular malware family.
The IsSpace malware sample, however, looks to have been updated since last we wrote on it. While the available commands from the command and control (C2) server remains the same, the URI structure of the network communication has been modified. Additionally, the installation routine for this malware family has been updated to be far less complex than previous discussed versions, favoring PowerShell to set persistence and forgoing the previously used side-loading technique. A more detailed analysis of the new instances of IsSpace may be found at the end of this blog post in the Appendix.
Infrastructure
A number of unique domains were employed by the various Trojans used in these attacks. For the numerous instances of sysget we observed, the following domains were observed for their C2:
kr44.78host[.]com
gtoimage[.]com
gogolekr[.]com
All of the above domains have Chinese WHOIS registrant details. Additionally, the gotoimage[.]com and trend.gogolekr[.]com are both registered to the same registrant and resolve to the same netblock of 104.202.173.0/24.
The instances of TidePool identified communicated with the following C2 servers:
wikaba[.]com
ssl443[.]org
skywave[.]top
These domains did not have many definitive relations with the sysget C2 servers except for cool.skywave[.]top, which shared a unique registrant email with the sysget C2 server of trend.gogolekr[.]com. Additionally, the geographic region of the resolved IPs was consistent with the previous set, as they all resolved to various regions in southeast Asia. Specifically, the domains resolved to China, Korea, and Taiwan in the past six months.
The IsSpace samples resolved to the following domains:
dppline[.]org
matrens[.]top
These domains had no apparent connections to the previously discussed C2 servers, other than the fact that they resolved to Korea and Hong Kong respectively. Additionally, the registrar of ‘Jiangsu Bangning Science and technology Co. Ltd.’ was used for a large number of domains. A full graph of the relations between the various attacks is shown in Figure 6.
Figure 6 Relationships between attacks
Conclusion
The DragonOK group are quite active and continue updating their tools and tactics. Their toolset is being actively developed to make detection and analysis more difficult. Additionally, they appear to be using additional malware toolsets such as TidePool. While Japan is still the most-targeted region by this group, they look to be seeking out victims in other regions as well, such as Taiwan, Tibet, and Russia.
Palo Alto Network customers are protected against this threat in the following ways:
Malware families are tagged in AutoFocus via a variety of tags (TidePool, NFlog, Sysget)
The following IPS signatures detect malicious network traffic:
IPS signature 14365 (IsSpace.Gen Command And Control Traffic)
IPS signature 14588 (Suspicious.Gen Command And Control Traffic)
IPS signature 13574 (NfLog.Gen Command And Control Traffic)
IPS signature 13359 (Nflog.Gen Command And Control Traffic)
All samples are appropriately marked malicious in WildFire
Appendix
CVE-2015-1641 Exploit and Shellcode
This particular group uses a very specific shellcode payload when exploiting CVE-2015-1641. This CVE is memory corruption vulnerability which allows for arbitrary code execution in various versions of Microsoft Office, including 2007, 2010, and 2013.
The shellcode begins by dynamically loading a small number of API functions from kernel32. A number of hashes are included that represent function names, which have a rotate right 7 (ROR7) operation applied against them before being XORed against a key of “\x10\xAD\xBE\xEF”. The ROR7 operation is a very common technique in shellcode to obfuscate what functions are being called. The author added the XOR operation to add another layer of obfuscation.
Figure 7 API function hashes contained in shellcode
After the shellcode loads the necessary API functions, it proceeds to seek out a number of markers that will mark the beginning and ending of both an embedded malicious payload, as well as a decoy document.
The malicious executable is marked with a starting point of 0xBABABABABABA and an end marker of 0xBBBBBBBB. The decoy document is found immediately after the end of the malicious payload, and has an end marker of 0xBCBCBCBC. Both executables are encrypted with a 4-byte XOR key. Should the original data contain 0x00000000, it will not have the XOR applied against it.
The malicious payload is XORed against a key of 0xCAFEBEEF and the decoy document is XORed against 0xBAADF00D. The following script may be applied against the RTF document to extract both the malicious payload and the decoy:
raise Exception(“Unable to find correct offsets for document.”)
return[exe_data,doc_data]
def main():
input_file=sys.argv[1]
input_fh=open(input_file,‘rb’)
input_data=input_fh.read()
input_fh.close()
exe,doc=extract(input_data)
filename=“{}.exe”.format(input_file)
output_file=open(filename,‘wb’)
output_file.write(exe)
output_file.close()
print“[+] Wrote {}”.format(filename)
filename=“{}.doc”.format(input_file)
output_file=open(filename,‘wb’)
output_file.write(doc)
output_file.close()
print“[+] Wrote {}”.format(filename)
iflen(sys.argv)==2and__name__==“__main__”:
main()
When both files are decrypted, they are written to the following location in the %TEMP% directory:
../..exe
../..doc
Note the initial ‘..’, which represents the parent directory of %TEMP%. This coupled with the unusual names of ..exe and ..doc make this particular shellcode very unique, which is one way we have attributed these samples to the same group. After the samples have been written, they are executed via calls to WinExec.
Sysget v2 Analysis
One of the fundamental changes witnessed in the second iteration of sysget is removing support for Windows XP and lower. Other changes include modifications to the URIs used for network communication.
Like the original version of sysget, sysget v2 still uses a named event of ‘mcsong[]’ to ensure a single instance is running at a time. It proceeds to make attempts at copying itself to the %STARTUP%/notilv.exe path. However, it uses COM objects to perform this action that is not available in Windows XP, which prevents the malware from installing itself to this location. While the remainder of the malware operates as expected, it will not survive a restart of the system.
Sysget proceeds to make an attempt at reading the following configuration file. This filename and path has changed since the original version, and is consistent in the subsequent versions.
%APPDATA%/vklCen5.tmp
This configuration file holds both a unique victim identifier, as well as a key that is used to encrypt HTTP traffic. It is encrypted using the AES-128 encryption algorithm, using a static key of ‘734thfg9ih’. Using AES-128 is a change from the previous version, where RC4 was used for all encryption operations. The following Python code may be used to decrypt this file:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
import sys
import base64
from wincrypto import CryptCreateHash,CryptHashData,CryptDeriveKey,CryptDecrypt
def decrypt(data,original_key):
CALG_AES_128=0x660E
CALG_MD5=0x8003
md5_hasher=CryptCreateHash(CALG_MD5)
CryptHashData(md5_hasher,original_key)
key=CryptDeriveKey(md5_hasher,CALG_AES_128)
decrypted_data=CryptDecrypt(key,data)
returndecrypted_data
arg=open(sys.argv[1],‘rb’).read()
print repr(decrypt(arg,‘734thfg9ih’))
When executed against an example configuration file, we see the following output, which includes the two pieces of data noted previously:
The encryption of this configuration file is a new feature that was not present in the original version of sysget.
If this file is not present on the system, the malware will attempt to retrieve the necessary information via a HTTP request. The following request is made to the remote command and control server. Note that the full URI is statically set by the malware sample.
The server responds with the following data, encrypted using the same technique previously described with a static key of ‘aliado75496’. Once decrypted, we see the following example data being sent back to sysget:
gh1443717133\n1059086204\n
The first string is used as a key for all subsequent network communication. The second string is treated as a unique victim identifier. This data is encrypted using the key of ‘734thfg9ih’ and written to the %APPDATA%/vklCen5.tmp file.
After this information has been obtained, the malware proceeds to enter its command and control loop. An HTTP request such as the following is made to the remote server. Note that the ‘mid’ GET variable holds the MD5 hash of the previously obtained victim identifier. The remaining data in the URI is hardcoded.
The response is encrypted using the unique key that was obtained previously. Should the response contain ‘Fatal error’ unencrypted, no further actions are taken by the malware sample. Once decrypted, the response may have one of the following two choices, and their accompanying purpose. Alternatively, if a raw command is provided, the malware will execute it and return the results.
Command
Description
goto wrong “[file_path]”;\n
Read a specific file and return its contents.
goto right “[filename]” “[identifier]”
Write a given file. The identifier is used to retrieve the file’s contents in a subsequent HTTP request.
When the ‘goto wrong’ request is made, a HTTP POST request is made to the following URI. In the following URI, the ‘list’ parameter contains the MD5 hash of the victim’s identifier.
The contents of this POST request contains the victim’s identifier, as well as the file’s contents encrypted with the unique key. The first 50 bytes are reserved for the victim identifier, as shown below:
If the ‘goto right’ command is used, the malware will make a subsequent request to the following URI. The ‘cache’ variable holds the unique identifier that was provided in the ‘goto right’ command.
Once the file contents are obtained, they are written to the specified filename in the %STARTUP% folder.
When a raw command is received, the malware will upload the results to the following URI via a POST request:
/index.php?type=register
An overview of the network communications exhibited by sysget version 2 can be seen in the figure below.
Figure 8 Sysget version 2 command and control flow
Sysget v3 Analysis
Some of the biggest changes witnessed in version 3 of sysget includes numerous anti-debug and anti-vm detections added, as well as the encryption of the URIs used for network communication.
When the malware initially executes, it performs the following checks to ensure it is not being debugged and not running in a sandbox or virtualized environment.
Should these checks return false, the malware proceeds to enter its installation routine. The malware originally copies itself to a temp file in the %TEMP% directory with a filename prefix of ‘00’. It proceeds to append 4194304 bytes of randomly chosen data to the end of this file. The increased filesize may have been added by the author in an attempt to thwart sandboxes that impose filesize limits on what is saved and/or processed. Finally, the malware copies the original file from the tmp path to the %STARTUP%/winlogon.exe path using the same technique witnessed in version 2. Sysget then writes a batch script in the %TEMP% folder with the following contents, cleaning up the original files and spawning the newly written winlogon.exe executable:
After installation, sysget will attempt to read the same %APPDATA%/vklCen5.tmp file as witnessed in the previous variant. A number of strings within the malware, including the ‘734thfg9ih’ key used to encrypt this file, have been obfuscated via a single-byte XOR of 0x5F.
Similar to previous versions, should this vklCen5.tmp file not be present on the victim machine, it will make an external HTTP request to retrieve the necessary information. The following request is made by the malware. Readers will notice that the URI has changed from previous versions in a number of ways. This version of sysget looks to always make requests to 1.php, which is hardcoded within the malware itself. Additionally, all HTTP URIs in this version of sysget are encrypted. The initial GET request made to retrieve the victim identifier and unique key is encrypted with a key of ‘Cra%hello-12sW’. The subsequent response containing this information is then decrypted using a key of ‘aliado75496’, which is consistent with previous versions.
This URI is consistent with the previous sysget variant. It would seem the authors simply have added this layer of encryption to hinder efforts to block the malware via network-based detections.
After this initial request to retrieve the victim identifier and unique key, sysget enters its command and control loop. This process is consistent with the previous version, but simply has the extra layer of encryption used for the URIs.
Sysget v4 Analysis
The fourth variant of sysget is nearly identical to the third variant. However, the main difference lies in the URIs used for network communication. In addition to the expected encryption of the URIs, this variant also mangles the base64 encoding that is performed afterwards. The following Python script may be used to de-obfuscate the base64 URI found in this variant:
Additionally, the C2 URI changes in this variant, from 1.php to 5.php
IsSpace Analysis
When initially run, IsSpace will create a unique event to ensure a single instance of the malware is running at a given time. This event name appears to be unique per the sample, as multiple samples contained unique event names. The following event names have been observed in the samples that were analyzed:
e6al69MS5iP
v485ILa3q5z
IsSpace proceeds to iterate over the running processes on the system, seeking out the following two process substrings:
uiSeAgnt
avp.exe
The uiSeAgnt string may be related to Trend Micro’s solutions, while avp.exe most likely is related to Kaspersky’s anti-malware product.
In the event uiSeAgnt is identified, the malware will enter its installation routine if not already running as ‘bfsuc.exe’ and proceeds to exit afterwards. Should avp.exe be identified, the malware enters an infinite sleep loop until a mouse click occurs. After this takes place, the malware proceeds as normal.
The malware then determines if it is running under Windows XP. In the event that it is, it will make a HTTP GET request to http://www.bing.com, presumably to ensure network connectivity.
If the malware is not running on Windows XP, it will attempt to obtain and decrypt any basic authentication credentials from Internet Explorer. This information is used in subsequent HTTP requests in the event a 407 (Proxy Authentication Required) or 401 (Unauthorized) response code is received during network communication.
IsSpace will then enter its installation routine, where it will first copy itself to the %LOCALAPPDATA% folder with a name of ‘bfsuc.exe’. It then sets the proper registry key for persistence by executing the following PowerShell command:
The malware then makes an initial HTTP POST request to the configured C2 server. It will make this request to the ‘/news/Senmsip.asp’ URI. The POST data is XORed against a key of “\x35\x8E\x9D\x7A”, which is consistent with previous versions of IsSpace and NFlog. Decrypted, the POST data reads “01234567890”. The C2 server in turn will respond with the victim’s external IP address.
Figure 10 Initial IsSpace beacon
IsSpace then spawns two threads that will make HTTP requests to the following URIs:
/news/Sennw.asp?rsv_info=[MAC_ADDRESS]
/news/Sentire.asp?rsv_info=[MAC_ADDRESS]
The ‘Sennw.asp’ POST requests that are made contain collected victim information. They, like other information sent across the network, are encrypted using the previously mentioned 4-byte XOR key. When decrypted, we are provided with information such as the following:
The information, delimited via ‘#%#’, is as follows:
Value
Description
60-F8-1D-CC-2F-CF
MAC address
172.16.95.1
External IP collected previously
172.16.95.186
Internal IP address
WIN-LJLV2NKIOKP
Hostname
Win7
Windows version
English(US)
Language
2016-12-20 16:27:12
Timestamp
Active
Malware status. May also be ‘Sleep’
xp20160628
Potential campaign identifier
IsAdmins / False
User admin status
The malware is expected to return one of the following two responses to this HTTP request:
Active
Slient (Note the typo)
In the event the response of Slient is received, the malware will stop sending out HTTP requests to the ‘Sentire.asp’ URI. Conversely, if the malware is set to the ‘Sleep’ status and the ‘Active’ response is received, it will begin the ‘Sentire.asp’ requests once more.
The requests to ‘Sentire.asp’ act as the main C2 loop, requesting commands from the remote server. The commands are consistent with previously observed instances of IsSpace, however, the URIs have been modified.
This post is part of an ongoing blog series examining “Sure Things” (predictions that are almost guaranteed to happen) and “Long Shots” (predictions that are less likely to happen) in cybersecurity in 2017.
It’s time again to make our annual cybersecurity predictions, and this year, I have the pleasure of doing two! Since my Magic 8 Ball hasn’t been too dependable in the past and inspecting animal entrails is not really my thing, I’ll go with a more useful and less messy approach of looking at trends. Calling the future is a pretty challenging task, but one’s probability of success could be much improved if looking at the trajectories of past events and extrapolating.
Holidays and Hurricanes
Speaking of trajectories, at the beginning of September, I had to make a go/no-go decision about my family vacation to Hawaii. For weeks I had been hyping up the trip to my three-year old daughter, who loves beaches and adores sea animals. However, looming ready to spoil our Labor Day–week vacation was Hurricane Lester, which had reached Category 4 status on its approach to the Hawaiian Islands. Much of the archipelago was already on watch as just days before, hurricane Madeline grazed Hawaii, fortunately leaving the islands intact, but still causing quite a stir.
Having been through two major hurricane events while living on Oahu, I knew of the devastation a direct hit could bring and thus my first instinct was to cancel the trip. At the same time, I couldn’t bear the thought of breaking my daughter’s heart after getting her hopes so high. Two-hours before our scheduled flight departure, Lester was still on course to hit the islands, and I was faced with a tough decision: cancel my trip and disappoint my little girl or fly anyway and hope that the hurricane changes its path at the last minute. I’ll keep the suspense high and tell you my decision later, but first, let’s get back to the predictions.
Cyber-hurricane watch is in effect
As I observe the movements of the cybersecurity industry, a couple of approaching “storm systems”– which I foresee causing potential devastation to critical infrastructure operators – are ransomware and cybersecurity regulations. The devastation for ransomware is more strongly related to critical service uptime and safety, while the impact of regulations comes in the form of administrative costs. With that said, here are my predictions for 2017.
Sure Thing: There will be public disclosure of an increasing number of successful targeted ransomware attacks to the OT environment of critical infrastructure each causing millions of dollars in losses.
Long Shot: A new transportation-sector cybersecurity regulations or legislation will be in the United States.
Let’s take a closer look at each prediction separately.
Ransomware in Critical Infrastructure
The direction of ransomware in critical infrastructure is pretty clear and concerning. In September of 2016, we heard of a concrete manufacturer who experienced significant downtime and other related financial damages caused by the successful ransomware attack. In 2016, there was the breach to an Electric Authority who while not an operator of the grid interacts with many of the organizations who do manage the local grid. Of more increasing concern was the breach to a Municipally-owned Electric and Water Utility. Here the attackers successfully breached the business network adjacent to the OT environment. This caused a reported $2M in remediation and legal costs. Highlighting the increasingly targeted nature of ransomware is the news of ICS-specific ransomware in July 2016. Here the E-ISAC reported ransomware apparently targeting Industrial Control Systems (ICS) in the form of a zip file named after a major supplier of ICS automation products.
These successful breaches have been to networks adjacent to OT and either did not cause downtime or, if they did cause downtime, had their impact contained to the ICS operator itself and did not affect services critical to the general populace. However, looking at where this is all headed, it is only a matter of time before there is a successful downtime-causing attack to a major critical infrastructure environment, such as the electric grid or transportation system supporting a large population.
The ability to gather intelligence for ICS environments, introduce ransomware, and make sure that it successfully compromises these specialized systems takes a lot of effort, possibly requiring the involvement of an insider. Hence, I believe that this attack will most likely involve well-resourced cybercriminals targeting an organization in an attempt to extract a hefty ransom. The impacted authority will be faced with a grave decision – pay the ransom in the hopes of quickly regaining functionality, or choose not to pay the ransom and instead remediate the situation with a functional disaster recovery plan and augment that with third-party resources and technologies whose total cost will end up far exceeding the ransom. None of us hopes this type of attack happens, of course, but such an event would cause the entire industry to wake up and think more urgently about how to safeguard ICS environments.
Regulations for the Transportation Sector
There are already cybersecurity regulations governing various sectors of critical infrastructure protection. These regulations include the NERC CIP (North American Electric Reliability Corporation Critical Infrastructure Protection) standards for the electric sector, CFATS (Chemical Facility Anti-Terrorism Standards) for the chemical sector, and the NRC (Nuclear Regulatory Commission) regulations for the nuclear power facilities. However, an area that has not had any cybersecurity regulations put in place is the transportation sector (and its widely varying subsectors). The importance of this sector is immense as the impact to daily life could be disastrous should key transportation services be disrupted. Consider that the transportation sector as defined by the U.S. Department of Homeland Security includes the following: aviation (including airports, aircraft, and air traffic control systems); mass transport and passenger rail; highway and motor carriers; maritime transportation systems; pipeline systems; freight rail; and postal and shipping. Yes, that’s about as critical as critical infrastructure gets.
Some cyber incidents to the airlines industry demonstrate why this is a major concern. In 2013 there was a cyberattack to Passport Control Systems at major airports leading to delayed departures and long waiting times for passengers. Also in 2013, APT campaigns involving Phishing scams were found to be targeting as many as 75 airports in the United States with some organizations successfully breached. More recently in 2016, an outage at a major airlines carrier, while not attributed to a cyberattack, led to a five-hour outage costing $150M dollars and 2,000 flights cancelled over two days.
To be sure, there already are transportation-specific ICS cybersecurity plans in place, such as those from the U.S. Department of Homeland Security involving guidance on best practices. However, for 2017, I think there is the potential for new cyber legislation or regulation that one of the many transportation sector oversight bodies issues under their existing authority, possibly involving rigorous audits and steep fines for violation. This potential for regulation speaks to the gravity of these real-world threats, given that both President-elect Trump and the Republican-led Congress are generally opposed to increasing the country’s regulatory environment.
It’s Not About Being Right or Wrong
So there are my predictions for 2017. It will be interesting to see just how close or far off I am, but measuring my ability to accurately predict the future is not really the objective here. Rather, the purpose is to bring to light some of the key trends in industrial cybersecurity to hopefully build awareness and drive action.
On the former prediction, the unfortunate truth based on what I’ve seen so far is that most OT organizations are ill-equipped to deal with sophisticated attacks. Ransomware is but one of many modern attack methods that call for a different defensive mindset and set of new protective technologies. Granted, OT organizations are waking up and modernizing their OT security, but there is a long way to go for most, especially in being able to stop more advanced attacks. As IT and OT integrate even more deeply, organizations need to educate themselves to find out what attackers are doing and the state of the art, in terms of cybersecurity best practices and technologies.
Similarly, transportation organizations, or more broadly, other critical infrastructure operators not subject to regulations today, need to plan for the potential of such cybersecurity laws. As these organizations plan for upcoming regulations, whether they get put in place next year or further out, it is important to remember that compliance doesn’t mean they are secure. Even a well-crafted regulation that promotes risk management rather than a culture of minimum compliance means that compliant companies establish a good baseline, but they need to strive for more. Fortunately, a good natural outcome of applying the best known practices and technologies is that there is a very good likelihood that one will exceed the requirements of cybersecurity laws and pass their audits with reduced effort and cost. Invest a little more time up front and make it easier on yourself later during the audit.
The decision
Going back to the critical decision I had to make about my family vacation, I ended up trusting my gut and cancelled our trip to Hawaii. We decided instead take a drive south to SeaWorld and the San Diego Zoo Safari, which my daughter absolutely loved. So all ended up well. As for hurricane Lester, it ended up changing its direction and, like Madeline, just grazed Hawaii to cause some heavy rain and winds, but nothing major. My initial reaction was that I made the wrong decision. However, considering the risk to my family’s safety, had I decided to go and the hurricane did hit, I still stand by my decision to forego the trip. The stakes were simply too high.
A parallel statement could be made for successful cyberattacks to critical infrastructure. A “roll the dice” approach is simply not an option. Millions of people are dependent on operators to be proactive and stop cyberattacks. Whether the cyber hurricane hits or not, one needs to strive for more than just hitting the minimum compliance requirements and invest in the capabilities to stop advanced cyberattacks.
At Palo Alto Networks we firmly believe that a key approach to stopping advanced attacks and reducing the efforts to deploy and administer cybersecurity is in adopting a prevention-focused cybersecurity platform that provides as much automation as possible. Learn more about our platform by accessing the following resources.
Join this on-demand webinar to hear from utilities and Palo Alto Networks experts on how to address ransomware.
Get an overview of our Next-Generation Security Platform for Critical Infrastructure by reading this white paper.
See how our Next-Generation Security Platform can be deployed to secure your industrial automation environment by accessing our Reference Blueprint white paper.
What are your cybersecurity predictions for the ICS industry? Share your thoughts in the comments below.
Hackers are becoming increasingly stealthy and creative, relentlessly trying to gain access to sensitive data, while organizations work tirelessly to prevent security breaches and data theft. In this complex game of cat and mouse, security practitioners are being forced to rethink how they identify and control traffic on the network, shifting to an application-focused approach, rather than port- and protocol-based policy, to defend against successful cyberattacks and uphold business integrity.
User-based access controls, based on user identity information, rather than IP address, allow organizations to safely enable applications traversing the network, make informed decisions on network access, and strengthen overall network security. Here are four reasons why you should take advantage of user-based access controls, called User-ID, on your Palo Alto Networks next-generation firewall (NGFW):
1. Complete Network Visibility
Improve network visibility by mapping network traffic to users, rather than IP address. Application visibility based on users provides an organization with a more relevant picture of network activity, along with the power to quickly determine associated risks and respond accordingly. User-based access policies can be applied to application, URL, and file type accessibility, reducing the organization’s risk of initial attack, lateral threat movement, and insider threats by ensuring that data movement to and from users is both allowed and approved.
2. Simple Security Policy; Simple Life
Security practitioners do not have the time nor resources to invest in tracking thousands of IP addresses and complex security rules. Access controls based on User-ID, user identity, who is allowed or required to do what, dramatically simplifies the rules and safely enables applications, while simultaneously reducing the administrative effort associated with end-user moves, adds and changes. User-based access policy eliminates the need for a multitude of location-specific rules, as well as the need to dynamically adapt to the most appropriate policy for individual users and user groups, even as users move around the office, or outside the corporate network with various devices on different network addresses.
3. Minimum Access; Maximum Control
End users – employees, customers, partners – must be able to access required information repositories, as well as the Internet, to perform various functions of their jobs. Leveraging user-based access controls to analyze application threats and web surfing activity in terms of individual users, or groups of users, ensures access to mission-critical resources, and restricts access beyond the scope of approved means. When determining accessibility parameters, align application usage with business requirements following the principle of least privilege – minimum access based on job requirements – and, if appropriate, inform users that they are in violation of policy, or even block their application usage outright. User-based policy follows users regardless of location or device.
4. Increased Security; Better Forensics
It’s important to have the right user-based access controls in place to manage the identities and access of both internal and external employees, customers and partners. Knowing who is using each of the applications on your network, and who may have transmitted a threat or is transferring files, reduces incident response times and allows for damage control if an attacker does successfully infiltrate. In addition, user-based access policy ensures an attacker will only gain access to a small portion of data on the network, rather than the entire net worth of information. For maximum security protection and breach prevention, employ the right user access to mechanisms not only on the applications and endpoints that users access, but also on the organization’s next generation firewall infrastructure.
To learn more about the benefits of leveraging User-ID, user-based access controls, on your Palo Alto Networks NGFW:
We hope 2017 finds you ready for another year of challenges, opportunities and achievements—much like the year we all have just enjoyed.
In 2016, ISACA moved forward as an organization with the support of its 215 chapters around the world working to increase our visibility, influence and impact, locally and globally. Perhaps most encouraging is the progress we are making as a valued professional community, which has occurred amidst rapid changes and increasing complexity in and around our key fields of interest—audit/assurance, information and cyber security, governance and risk. Highlights from 2016 included:
The growth of our community to 159,000 constituents worldwide;
A very inspirational and successful Global Leadership Summit (GLS) that brought together over 400 ISACA chapter, member and staff leaders in April, and has resulted in ongoing input on both ISACA’s current efforts and how best to shape the future of our organization;
Regional expansion of ISACA events: Our first Africa CACS conference was held in Nairobi, Kenya, in August. Two new cyber security conferences took place in November: CSX Asia Pacific in Singapore and CSX Europe in London;
Completion of the development work required to support the 2017 transition from paper-based to computer-based testing for ISACA’s core certifications (CISA, CISM, CRISC, CGEIT);
ISACA’s acquisition of CMMI, with plans to accelerate ISACA’s reach in fast-growing economies, including China and India, and to better engage and deliver solutions to enterprises, while highlighting the value members of our professional community deliver;
ISACA’s significantly increased engagement with government, including the EU, US, India, Israel, Jordan, China, Kenya and Singapore, with many others expressing interest or initiating a dialogue;
The launch of ISACA’s Connecting Women Leaders in Technology program, which has been well-received across our professional community, and offers opportunities to extend its impact going forward into 2017 and beyond;
Established business development initiatives to grow relationships with organizations that employ professionals in our community worldwide;
The recent deployment of the ISACA Member and Customer Experience Center which, in its first two months of operation, has already significantly improved response time and overall service levels, including reducing certification application processing time from eight weeks to three weeks, and responding to email inquiries in less than 72 hours.
The above is a small subset of all that has happened over the past year. These highlights, along with many other contributions and accomplishments, have helped lay the foundations for a very promising year ahead. In 2017, we will again expand our education and training programs; increase our research efforts and publications output; grow our collaboration with government, industry, and other strategic partners; launch a new digital presence; enhance member and customer service levels; and begin planning our 50th anniversary, with an aim of using this 2019 milestone as a means to further increase the visibility of our professions and to build our workforce of the future.
While our anticipated growth in 2017 will occur in a world that remains unsettled, we believe ISACA’s professional community is ready to meet the challenges that will ensue, and turn these challenges into opportunities in the spirit of ISACA’s purpose to help enterprises and people realize the positive potential of technology. We thank all of you for your support and efforts to date, and as we begin 2017, we wish you all a safe, healthy, productive and prosperous year ahead.
Christos K. Dimitriadis, Ph.D., CISA, CISM, CRISC, chair of ISACA’s Board of Directors and group director of Information Security for INTRALOT, and Matt Loeb, CGEIT, FASAE, CAE, Director and CEO, ISACA
