“It takes two flints to make a fire” has been attributed to noted author Louisa May Alcott and it truly symbolizes the teamwork that goes into delivering ISACA’s activities and resources, and specifically, theISACA Journal. Thousands of members have shared their time and expertise with the Journal since it was introduced in 1973 as a quarterly publication named The EDP Auditor Journal.
Since then it has grown in size and circulation and has earned a reputation as a highly respected global peer-reviewed source of practical knowledge. The Journal is consistently rated as one of the top member benefits and value and satisfaction are high across all job functions and global regions. According to the ISACA Member Needs Survey, 83 percent of members are satisfied with the Journal and 81 percent believe it is of value to members.
A cover of the ISACA Journal
from 2005
A cover of the ISACA Journal
from 2014
This is possible only because of the dedication of article authors and other volunteers, including contributing editors and editorial reviewers, who have been instrumental every step of the way. Two of these volunteers hit milestones this year—Steve Ross is marking his 15th year as author of the Information Security Matters column and after volume 6 (and nine years of contributions) Tommie Singleton is retiring from writing the IS Audit Basics column. Both of these columns are widely read and respected and have contributed to the knowledge and lively debate among many ISACA constituents.
Steve and Tommie are great representatives of the many members around the world who volunteer their time and help propel ISACA’s valuable publications, events, translations, research, certification programs and other resources, which are created to serve our constituents. This teamwork is priceless and I thank you all for making ISACA a worldwide leader and innovator.
Robert E Stroud, CGEIT, CRISC, international president of ISACA
Tor exit node in Russia spotted downloading malicious code.
Users of the Tor network now have one more reason to be cautious when using the service to browse the Internet or to download executable code anonymously.
A security researcher last week uncovered a malicious Tor exit node in Russia being used by unknown attackers to insert malicious code into files being downloaded by Tor users. Tor administrators have since flagged the node as a BadExit, meaning that Tor clients now know to avoid using the server.
Still, its presence on the network shows how Internet users are not immune to malicious downloads when using Tor, said Josh Pitts, security researcher at Leviathan Security Group who discovered the malicious node.
Tor is a network that allows users to browse the web anonymously. It uses a series of encrypted connections to route data packets in such a manner as to hide the true IP address of the person using the service. Instead of routing traffic via a direct path to a destination, Tor routes traffic through a series of servers distributed around the world with an exit node serving as the last server on the network before the public web. Between 1,100 and 1,200 servers currently serve as exit nodes on the Tor network.
Pitts discovered the malicious node while doing research on the threat to Internet security posed by unencrypted binary files. In a presentation at the DerbyCon security conference earlier this year, Pitts showed how binary files hosted without any transport layer security encryption on the web could be easily intercepted and tampered with when they are being downloaded.
According to Pitts, some 90% of the sites from which downloads are available do not use SSL/TLS encryption nor use digital signatures to prevent such tampering. As a result, hackers are likely inserting malicious code into binaries via man-in-the-middle attacks, Pitts had maintained at his DerbyCon presentation.
Pitts decided his best chance of catching binaries being maliciously tampered with during download was to look at traffic coming out of known Tor exit nodes. Using, a tool called exitmap, Pitts checked the nodes for traffic modifications and quickly discovered the malicious server in Russia.
Though this was the only malicious node that Pitts discovered, it is quite possible there are others similar nodes. “I may not have caught them, or they may be waiting to patch only a small set of binaries,” Pitts said.
The key takeaway here is that binary files hosted in the clear without any digital signature pose a danger and should be avoided, he said in an email exchange.
“Companies and developers that host static, compiled binaries and source code need to host it via SSL/TLS so that nobody can patch them [maliciously],” he said.
Though such binaries pose a threat to everyone, Tor users need to pay attention, he said. Users should be careful particularly about download Windows executables or raw binaries over Tor, he said,
“Tor is risky because you need to have good information security awareness when using it. Tor is not a beginner network. You need to have some sort of understanding that every exit node could be out to get you,” Pitts said.
The issue discovered by Pitts is not an indictment of Tor security or of the strength of its anonymity protocols. Even so, it is the second time the Tor Project has been in the news over something similar in the past one year. Last year, some people questioned whether the FBI had found a way to exploit an vulnerability in Firefox to disable Tor’s privacy protections.
Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year career at Computerworld, Jai also covered a variety of other technology topics including Big Data, Hadoop, Internet of Things, E-voting and data analytics. Prior to Computerworld, Jai covered technology issues for The Economic Times in Bangalore, India. Jai has a Master’s degree in Statistics and lives in Naperville, IL.
The past decade of Cybersecurity has been relentlessly focused on stopping threats at the network edge. The implicit assumption of this approach is that the interior of your network is a trusted zone, and everything outside is untrusted. With this idea in mind, vendors began offering more and more ways to scan traffic at this logical boundary, attempting to detect known threats and hopefully taking some type of blocking action against them.
For the better part of the past ten years, this approach was the only one offered, and did a reasonably good job at keeping organizations safe. Traditional IPS/IDS, stateful firewalls, web security – it all relied on scanning traffic and making binary “yes, no” decisions as it passed through. Typically these decisions were made on known-bad content; only able to stop what security vendors thought was malicious.
Then, adversaries and threats changed. They had been watching, learning, and understood that this “hard outer shell, squishy center” represented a golden opportunity to carry out their objectives. To the adversary, this meant that getting past the edge gave them free reign to move laterally within organizations, finding valuable intellectual property wherever it resides, and exfiltrating it out using undetectable protocols. The edge, and the legacy technologies that protected it, had become an easily evaded – and expected – barrier.
This all begs one simple question: Why would you only detect malware at the network edge?
Let’s take a step back and examine how a typical advanced attack works:
• Make an initial compromise via a spear-phishing email, which leads to an infected site with a drive-by download or a malicious attachment.
• This drive-by download exploits a zero-day vulnerability in a browser, or the malicious attachment exploits one in client-site reader software.
• In this case, the attacker has masked his traffic by compromising a benign site or using an exploit that has never been seen before, making it undetectable for traditional solutions.
• The attacker has now established a foothold through this exploited client, a base of operations for future activity.
• From here, the attacker will deliver the actual malicious payload, so-called 2nd stage malware. This will often be done over protocols such as FTP, using encryption, over non-standard ports.
• Once the malicious payload has been delivered, the attacker now has free-reign to pivot laterally within the organization, moving from the initial client toward their final target.
• Often, they will hop multiple times, and the steal data using evasive means.
In this example, the perimeter has become a trivial “wall” for the adversary to overcome. The combination of unknown threats and persistent action within the organization itself is a very common method for truly advanced attackers.
Now, going back to the initial question: what if your entire organization’s network was able to detect and prevent this attack in multiple places? Not only this, but what if your security devices automatically augmented your security posture by discovering new threats and creating new protections?
Now your infrastructure has become an adaptive security framework that is tailored toward how advanced threats operate today. In order to gain this pervasive functionality, there are a few typical places where security devices can be deployed:
• Internet Edge
• Data Center Edge
• Between Virtual Machines in the Data Center
• On Mobile Devices and Endpoints
With this type of architecture, new threats are being discovered at each location in the network, and protections created. This intelligence is then automatically fed into every single security device wherever they are deployed. This gives you the advantage, instead of the adversary, as you are now increasing the probability of stopping an attack at each location, at each stage in the attack kill-chain.
The network edge is the ideal location for quickly preventing the vast majority of attacks, but looking forward, you should consider how pervasive deployments can stop the new breed of advanced attack.
Scott Simkin is a Senior Manager in the Cybersecurity group at Palo Alto Networks. He has broad experience across threat research, cloud-based security solutions, and advanced anti-malware products. He is a seasoned speaker on an extensive range of topics, including Advanced Persistent Threats (APTs), presenting at the RSA conference, among others. Prior to joining Palo Alto Networks, Scott spent 5 years at Cisco where he led the creation of the 2013 Annual Security Report amongst other activities in network security and enterprise mobility. Scott is a graduate of the Leavey School of Business at Santa Clara University.
Security vendor Proofpoint warns in a new report that a “malvertising” campaign has been launching ransomware attacks against users of numerous high-profile websites, including search site Yahoo, dating site Match.com, and an AOL real estate site.
Proofpoint says it saw a surge earlier this month of malvertising exploits involving attackers serving real-looking advertisements that harbor malware on legitimate advertising networks.
“These types of malware infections are particularly effective because often the end user is not aware they have been infected,” says Mark James, an information security researcher at anti-virus firm ESET. “What would appear as an ordinary [legitimate] advertisement on a website can contain code that once the advertisement is clicked will infect your systems and could still deliver the advertised product.” Attackers often vary their attacks based on geography, which can make related malvertising campaigns difficult to spot, at least until the related levels of activity reach a “significant” level, Proofpoint says.
In the case of this criminal campaign, attackers’ malicious advertisements first targeted website users with the FlashPack Exploit Kit, which is designed to automatically exploit a number of known vulnerabilities in users’ browsers and browser plug-ins. If successful, the exploit kit then installed ransomware – malware that encrypts all data on a user’s PC and then demands a payment for the decryption key – called Cryptowall 2.0.
Tracking Cryptowall 2.0
The 2.0 version of Cryptowall was first spotted earlier this month by Finnish anti-virus firm F-Secure, which says the malware is using a custom component that allows it to communicate with command-and-control servers via the anonymizing Tor network, which helps disguise related infections. F-Secure says it first spotted criminals testing related tweaks to Cryptowall 1.0 this past summer, after which the changes were formally packaged up and released as Cryptowall 2.0. “We expect to see a lot more of Cryptowall 2.0 in the near future,” F-Secure trainee Artturi Lehtiö said in an Oct. 2 blog post.
That prediction soon came to pass. Proofpoint says it saw the malvertising campaign begin in late September. But related attacks didn’t spike until earlier this month, when they grew to expose approximately 3 million website users daily to related attacks.
Proofpoint says it contacted affected advertising networks, and by Oct. 18, they’d blocked the accounts that were being used to serve the malware. “The sites themselves were not compromised; rather, the advertising networks upon which they relied for dynamic content were inadvertently serving malware – which in turn, was not due to an explicit compromise of the networks; rather, it was due to the networks accepting ads from a malicious source without [proper] screening,” Proofpoint says.
While AOL and Match.com didn’t immediately respond to a request for comment about the Proofpoint report, a Yahoo spokeswoman confirms that the company has taken measures to block such attacks. “As soon as we detected the incident, we promptly removed the advertising and have continued to monitor and block any advertising being used for this activity,” she says.
Meanwhile, attackers continue to use Cryptowall for other in-the-wild attacks. Firewall vendorPalo Alto Networks reports that since Sept. 30, it’s spotted 84 new Cryptowall 2.0 variants. These variants target consumers “primarily through e-mail attachments but also through malicious PDFs and Web exploit kits,” it says. Those malicious PDFs would target users via phishing attacks, meaning the malicious documents would arrive attached to fake but real-looking e-mails.
Exploit Kits
While attackers continue to develop and refine their ransomware, the exploit kits they’re using to install Cryptoware – and numerous other types of malware – on victims’ PCs likewise continue to evolve. That’s due in large part to market demand: Exploit kits are predicated on exploiting a user’s PC through any means available, and security experts say there’s fierce competition among exploit-kit authors in search of more paying subscribers for their crimeware.
One currently popular crimeware kit, for example, is the Fiesta exploit kit, which security researchers at Cisco describe as being “aggressive” because it includes the ability to exploit not only common Java vulnerabilities, but also bugs in Microsoft Silverlight. While Oracle and Microsoft have released related patches, many users and businesses fail to install those updates in a timely manner, thus leaving them vulnerable to exploit-kit attacks.
After vendors release a security update for a product to fix flaws, exploit kit authors typically reverse-engineer the fixes to identify the flaws, and then add the ability to exploit those vulnerabilities to their kit.
How quickly do exploit kits get updated to take advantage of the latest flaws? This week, the Fiesta exploit kit reportedly received an update that allows it to exploit a Flash flaw that was patched by Adobe only last week. The “weaponized” version of the Flash flaw – an integer-overflow bug that’s been designated CVE-2014-0569 – was discovered by the malware researcher “Kafeine,” who maintains the “Malware don’t need Coffee” blog. Kafeine reports that the competing Angler exploit kit may also now be able to exploit the flaw.
In other words, just one week – or less – elapsed between Adobe issuing a public warning as well as related update that fixes the flaw, and attackers integrating the vulnerability into an exploit kit. That short timeframe shows the challenges facing consumers and enterprises that must keep their browser plug-ins – especially Flash and Java – up to date, or face a nearly constant risk of being hacked.
“The bad guys are not going to run short of vulnerabilities they can weaponize at a quicker rate than ever before,” security researcher Jérôme Segura, who works for anti-malware software firm Malwarebytes, says in a blog post. “This leaves end users with very little room for mistakes, such as failing to diligently apply security patches sooner rather than later.”
Follow Mathew J. Schwartz on Twitter: @euroinfosec
I attended the second National Institute of Standards and Technology (NIST) Privacy Engineering Workshop on behalf of ISACA, which was held in September in San Jose, California, USA. NIST took the information that they collected at their first workshop in April 2014 and put together a proposed high-level draft of the beginning of what will eventually become the privacy engineering framework—the “Preliminary Concepts” that will ultimately become integrated with the U.S. Framework for Improving Critical Infrastructure Cybersecurity, which was published early this year.
This workshop focused on four primary activities:
Reviewing the proposed privacy engineering definitions
Reviewing the proposed “System Privacy Risk Equation”
Determining a lexicon of privacy objectives, establishing common terms and categorizing potential privacy harms
Hearing from engineers, privacy experts and privacy advocates about additional issues
Proposed Privacy Engineering Lexicon
If engineers are expected to be able to understand privacy principles and then build privacy controls into their systems, devices and processes to effectively protect privacy, then they must be operating under a common vocabulary to understand the terms in the same way across the enterprise and then consistently implement the privacy controls. Some of the terms proposed by NIST, based upon their research and feedback from the April workshop, include three primary privacy engineering objectives and some primary privacy terms that all engineers need to know and understand.
The proposed privacy engineering objectives include (with my interpretations shown):
Predictability: These are actions to support reasonable assumptions individuals have about how their personal information is collected, used and shared.
Manageability: These are actions to allow individuals to access, correct, delete and selectively disclose their associated personal information as they determine to be appropriate.
Confidentiality: These are actions to ensure only authorized access to personal information occurs.
There was also discussion of the need for a possible fourth objective: data subject disclosure and rights. However, as various speakers and attendees pointed out, this is something that could be a challenge to actually engineer.
A few of the key privacy terms proposed by NIST include:
Data Actions: The typical information systems operations where personal information is involved.
Problematic Data Actions: These are data actions taken with personal data that violate the objectives of predictability, manageability and confidentiality. For example, distortion, misappropriation and surveillance, just to name a few.
Context: A critical term for engineers to understand. This is a concept that I emphasize all the time to my clients and in the classes I teach. It is also something most systems engineers do not take into consideration Context refers to the actions that should be taken based upon the reasons personal information is collected, and the ways in which it was intended to be used.
Defining Categories of Privacy Harms
NIST has proposed the following categories of privacy harms to be addressed by the privacy engineering framework.
Loss of Self-Determination: These would include loss of autonomy, exclusion, and loss of liberty.
Discrimination: These would include stigmatization and power imbalance.
Loss of Trust: This would include situations where a breach of promises has occurred.
Economic Loss: Direct financial losses resulting from identity theft and other misuse of personal information.
I firmly believe physical harm and safety should be another category added to the list. Here are just two considerations to support this.
We now have many devices that attach to individuals, and are used by individuals, to control their health, environment, etc. If the personal information and associated data within these devices was inappropriately accessed, used, altered, etc., it could result in physical harm to the associated individuals.
The types of surveillance methods and technologies continue to proliferate. They could be used to locate individuals, determine when individuals are alone, and reveal other aspects of an individual that could enable a malicious individual to bring harm to the individual in ways that could not occur without these surveillance methods and technologies.
Proposed System Privacy Risk Equation
NIST created a proposed “System Privacy Risk Equation” to help engineers to determine privacy risks in a similar way to how they use the information security risk formulas to determine information security risks. The big difference, though, is that the components focus on the likelihood of harm to the individuals involved, not to the organization itself. Which makes sense since the focus of privacy is on the individual.
The proposed System Privacy Risk Equation was presented as a diagram. Here is my interpretation in a more mathematical representation:
System privacy risk is the risk of problematic data actions occurring during
(Personal Information Collected or Generated +
Data Actions Performed on that Information +
Context)
= System Privacy Risk
One concept missing from this formula is stakeholder input. Without such input, it will be very hard to truly determine the associated privacy risk. I will look for this to be included in the updated equation, based upon discussions at the workshop.
Additional Issues to Address
In addition to the components of the proposed framework above, some of the additional issues that attendees expressed a need to add included:
The need for basic privacy education for all involved with engineering privacy controls, in addition to providing detailed guidance documents and case studies
Related to this, the need to educate the public on what is reasonable to expect from organizations with regard to preserving their privacy, and what they themselves need to take responsibility for
The establishment of metrics to measure how well each of the privacy areas are being addressed within the organization, and to support a determination of an organization’s privacy program maturity model
Addressing how engineers can include privacy actions within existing systems and software development models, such as agile and waterfall methodologies
The need to shift the business view of privacy from being a compliance checklist responsibility to being a more holistic evaluation of privacy risks activity
Privacy is about the individual; security is about the business
A couple of recurring thoughts that were described during the workshop that are very important points for organizations to be able to effectively understand and then take appropriate actions to preserve privacy are:
The primary focus for privacy risks and mitigations generally is on individuals. This is different than the primary focus for information security, which generally is on the business.
Privacy must become part of the business culture and be addressed throughout every aspect of business activities where personal information is involved in any way.
Going Forward
This was an important next step toward establishing actionable privacy standards to include within the US Cybersecurity Framework to provide a reference that engineers will be able to effectively utilitize within their current systems and software development frameworks to help build in the controls currently missing that are needed to most effectively protect personal information and mitigate privacy risks. I do not see this as the last workshop, however; there were several issues that were left open and some that were not addressed at this workshop. NIST also emphasized that the privacy engineering initiative was a distinctively separate effort from the cybersecurity work, implying that there would be at least another workshop down the road.
I look forward to seeing the resulting NIST Interagency Report (IR) that Naomi Lefkovitz indicated would be created as a result of the workshop, and then attending the next workshop where the Privacy Framework likely will be finalized.
