One of the key advantages of Java lies in its ability to work across platforms. In general, if you develop your application or applet in Java, it should work across any number of operating systems or browsers that support Java so that you don’t have to rewrite your application for each operating system. Of course, such broad support also means that a vulnerability in Java has the potential to apply across platforms as well.
This means there is a vast, sprawling attack surface of systems that could be impacted and this leads to lots of work for IT security. Updating a few IIS webservers is child’s play compared to updating the Java Runtime Environment (JRE) of every Java-enabled laptop, server and computing device, meaning that updating vulnerable systems is slow, laborious and prone to missing a device.
Exploit-Facing Signatures (A Slight Return)
Unfortunately, the challenges of Java exploits are not simply limited to a large attack surface. Java exploits pose challenges to IPS solutions that are potentially even more insidious.
At the heart of the problem is the difference between vulnerability-facing IPS signatures versus exploit-facing signatures. An exploit-facing signature is a simple signature that directly matches a specific exploit payload. However, there are often multiple ways that a given vulnerability can be exploited. As a result, more sophisticated IPS vendors began to write signatures that targeted the underlying vulnerability as opposed to each individual, specific exploit. Thus, these “vulnerability-facing” signatures would provide protection against many variants of an attack and have proven to be the far more effective approach for modern-day IPS products.
The problem is that the nature of Java and the JRE make it very difficult to write vulnerability-facing signatures. Java applets are typically delivered via .JAR files, which contain Java-class files, which are then run in the Java Runtime Environment. This introduces a subtle but very important shift. Unlike a traditional attack where the exploit is passed directly over the network, the Java exploit is carried within the java class file. Instead of seeing the actual attack, security solutions see “the code of the code” so to speak. And there are a very large number of ways that the actual malicious payload can be obfuscated in the class file. The class file can be changed, and the payload itself can be re-encoded or reflected.
In short, this means an attacker can create many variants of JAR files and Java-class files that look unique but carry the same underlying exploit. This is akin to how attackers can simply re-encode malware in order to avoid traditional antivirus signatures.
Blending Security Controls
Dealing with Java vulnerabilities requires a layered approach. The first step is for an organization to understand precisely where and why Java is needed. Based on the rate of newly discovered vulnerabilities, security teams should assume that Java is and will continue to be vulnerable. When and where possible, Java should be disabled in order to reduce the attack surface. This is especially true of internet-facing systems. In situations where Java is absolutely required, users should consider moving to a two-browser approach, with one browser that is used to access internal Java-based applications, and another browser with Java disabled for browsing the Internet.
Further, security should enforce strict control over JAR files and Java-class files. In many cases these files can be blocked outright, or only allowed from very specific trusted sources. It’s also important to know that JAR files are essentially specialized ZIP files, so controls should be configured to inspect within ZIP files for Java-class files as well.
In terms of prevention, teams should aggressively maintain their IPS solutions and push their IPS in terms of coverage for newly identified vulnerabilities. Additionally, teams should pursue virtualized analysis of unknown files to identify threats that may avoid the IPS.
These are a few simple suggestions, but as with any type of vulnerability, the key is to weigh the risk of a technology against the reward for the enterprise. For many enterprises the rewards of Java have considerably diminished over the years, while the risks are growing exponentially. So many organizations will need to take a long, hard look at Java and answer for themselves if it’s worth it.
Wade Williamson is a senior security analyst at Palo Alto Networks. Reprinted with permission from Anthem, the publication of the Northwest Credit Union Association (www.nwcua.org).
Three years ago, Purdue Federal Credit Union wanted to enhance its "big browser" online banking platform to better serve its approximate 62,000 members. Now, after two years of successful implementation, the credit union has increased its online banking membership by 25 percent.
"Converting to a new system of any kind is probably the largest, most complex project a financial institution can undertake and with it comes many challenges," said vice president of information technology Scott Ksander.
From past experiences of converting other systems and knowing what can potentially happen, we didn't anticipate that it would go as smoothly as it did. Our members didn't even notice—that's how smooth it was."
When the decision was made to find a new online banking solution, Ksander's 15-person IT department researched countless vendors. In 2010, ACI WorldWide's Architect Banking solution was selected for implementation and over the course of the following year the solution was integrated.
"As is always the case, we use our internal staff as guinea pigs," said Ksander. Along with the IT department, roughly 85 of the credit union's approximate 200 employees also tested the product. "Since we are all members, we utilize many employees who are early adopters and who always give great feedback."
Purdue FCU uses Fiserv's Spectrum for its core operating system. To ensure a successful conversion, Ksander's project team worked closely with an ACI contact to monitor progress, which required weekly meetings. While the integration went well, Ksander said it was important to determine that the third-party vendor could make a seamless transition without interfering with existing operations.
"One of our requirements was being able to add uniqueness, which was more so aesthetic changes, such as where the member account button is, or soon we will be adding a rewards program button," said Ksander.
One “Huge” Concern
Security is a "huge" concern for Ksander, who said that while he takes the highly publicized denial of service attacks (DDoS) seriously, he feels there is a "little over-stirring of the pot" by the media. "Security is half of what I think about on a daily basis and our job is to mitigate concerns," said Ksander. "This new system is encrypted and secure and we continually offer member education."
With 62,000 members, the $750-million Purdue FCU has experienced 25 consecutive months of online banking growth. In April, nearly 56 percent of members were active with online banking, which means they accessed accounts within 30 days. This also marked a 22-percent increase in transactions, such as address changes, transfers, and stop-payments. And bank-by-phone transactions have been reduced by 20 percent. Ksander explained that ACI Architect provides members with an intuitive, personalized experience. For example, they can select which account to act as the primary source for overdraft coverage through their online banking account. And they can renew or move an expired Share Certificate (CD) to a savings account through the online platform. Previously, members were required to visit a branch or speak to a representative.
"Not only are we able to customize the banking experience, we now have access to unique marketing capabilities and options that allow us to evolve as our members' needs change," said Ksander.
Big Browser vs. Small Browser
With a tech-progressive member base, due in part to its Purdue University members, the credit union is looking at two models, one being traditional home PC banking, the other being smart phone/mobile banking.
"We are trying to determine big browser versus small browser," said Ksander. "There has been a metamorphosis of ideas. First it was online banking and then came mobile banking. We used to think there was a correlation. Now we see these as two separate banking channels."
To better address the needs of its growing mobile banking demographic, Purdue FCU is in the process of developing an in-house mobile app that will launch in September. "The new students coming to Purdue have had mobile technology for at least eight years, since fifth or sixth grade," said Ksander. "We don't have to educate them on the joys of e-commerce. We have to attract them and familiarize them with our services."
While Ksander said he is curious to see what application-big browser or small browser-will define the online banking model in the future, he is certain that both categories will be viable channels. "I wish I knew the answer and am curious to see what happens, but electronic access to banking will continue to grow."
This article appeared at www.cujournal.com and is reprinted with permission.
When the technology and Wall Street pundits weighed in with their first impressions of the Galaxy S4 smartphone that Samsung recently unveiled, they framed their comments in the metaphor of a classic bout between Apple and its main rival. Did Samsung knock out Apple with an innovation it can’t match? Will Samsung’s bulging basket of goodies win over customers? And, of course, there were the inevitable comparisons of showmanship: Samsung’s bevy of Broadway actors at Radio City Music Hall vs. the man in blue jeans and black turtleneck saying, “One more thing . . .”
But if you reframe the way you evaluate Samsung’s top-of-the-line smartphone, it becomes clear that there is a winner: the mobile ecosystem. And that makes this good and important news for consumers and the financial services industry.
As Mary Monahan wrote in her February analysis of trends driving mobile imaging, 2012 marked the turning point when mobile-phone owners were more likely to tote a smartphone than a feature phone (52% vs. 49%). Whether you believe the S4 is truly innovative or feature creep, the reality is that this device only speeds the day when virtually every American will tote a smartphone and will use it in everyday ways for monitoring and managing their finances.
Is an individual consumer likely to base a phone-buying decision on the fact that the S4 boasts 13- and 2-megapixel cameras, eight core processors, 441-pixel retinal display, microSD expandable up to 64 gigs, dual-camera display, and so forth? Is that significantly better than the iPhone 5?
Maybe not.
But the fact that the two leading smartphone manufacturers have raised the bar on the technological quality of power of smartphones means that all rivals must raise their game. In short order a critical mass of smartphones will have those capabilities.
And because these devices are more powerful, the financial services industry can be even more innovative with things such as mobile deposit, mobile bill pay, document scanning, “face-to-face” customer service with video, card-not-present online and mobile purchases, digital account opening, financial alerts that can be evaluated with a hovering fingertip, and the overall speed and quality of conducting financial transactions on a mobile device. Don’t forget that arguably the most captivating mobile-banking feature to date—mobile deposit—truly couldn’t take off until 2-megapixel cameras became common features.
As the pundits rightfully noted, consumers might not discern much additional quality when they take snapshots at the beach. But they are likely to find their smartphones are a whole lot more useful and essential when they can photograph checks in low light, capture documents with tiny legal fine print, or scan documents that range in size from a driver’s license to a poster—and then process that information in the blink of an eye to satisfy our demand for fast transactions.
So, who’s the winner of the latest round of Samsung vs. Apple bout? Consumers.
Mark Schwanhausser is director of omnichannel financial services for Javelin Strategy and Research (www.javelinstrategy.com). Reprinted with permission.
The last year has seen a huge increase in the participation in the CUFX effort. The CUFX organization has grown from a handful of participants to over 200 team members. This includes industry leaders from credit unions, core processors, application providers, and payments providers.
Click here to read more about the accomplishments and current work in progress for this innovative group.
Many marketing researchers gloss over articles with “Big Data” in the headlines because the resources necessary to exploit Big Data are just too…big.
But the concept should encourage credit unions to think about the other data sets to which they have access and how to leverage them, say David Cooper and J. Paul Leavell in their report, “The Real Question is How Little is Little.”
Cooper is vice president of information systems for $287 million asset Charlotte (N.C.) Metro Federal Credit Union; Leavell is the credit union’s senior marketing analyst.
Big Data describes large volumes of high-velocity, complex, and variable data that are difficult if not impossible to manage and analyze within the existing frameworks of most companies.
Big Data can translate into a big payoff, but even companies with abundant resources should start by examining “Little Data”—information you can capture and analyze right away.
There’s a lot of low-hanging fruit here, Cooper and Leavell say.
If your credit union tracks automated clearinghouse (ACH) payees, for example, can you find insurance payees and leverage them to cross-sell insurance products to members you know are using another firm?
Once you’ve capitalized on those opportunities, turn your attention toward “Middle Data”—information an organization collects but is not in a position to analyze, or would be able to analyze if it were available.
Consider that a credit union tracks debit, credit, and ACH transactions, including the amount and payee of each, but it doesn’t have the resources to put that information to use.
But if you knew which members had recent inquiries on their credit reports, staff could reach out to them for loan offers.
In weighing the return on investment for data projects, keep in mind that even moderate efforts can create efficiencies. Emphasizing these concepts can allow for more robust service to members and generate revenue streams in novel ways.
(Via Credit Union Magazine)
| Home | News Archive |