Looks like there are quite a few issues emerging with various systems and components that many banks and such use for their core processing. The last few weeks have seen issues in Oracle, MySQL, AIX, of course Windows and various supporting tools and services.

Given the importance of core processing availability to most financial institutions, many are hesitant to patch their production systems associated with these critical functions. However, just the opposite should be true. These systems should be among the first patched to various vulnerabilities – of course – once a patch has been properly tested and vetted in their backup, lab or QA environment (they all have those, right?).

Certainly, increased pressure on patching these systems is coming from legal compliance and regulatory requirements, but financial organizations should ensure that they have an action plan for maintaining the patching and security of these systems – regardless of, and in light of, their criticality to the life of the organization. Taking a “wait and see” or “it’s working so don’t mess with it” approach could be a severely damaging error on the part of IT and management.

Core processing vulnerabilities are going to continue to emerge and present themselves as critical issues. Getting a process for managing them put into place is an excellent idea, the sooner the better.

I just wanted to post this pointer to another article of mine that ITWorld is running. This one is an explanation of some ideas of different approaches to doing security testing of applications.

If you are considering app testing, and want to get an overview of pent testing, code review and hybrid processes, this is probably a good start. You can then dig deeper into the mechanisms and such via sites like OWASP, SANS, etc.

You can find the article here.

My column at security.itworld.com is now running an article I wrote about the key ideas behind risk assessment, and the top three things that organizations need to know when they are considering risk assessments.

You can find it here.

I especially think that more organizations need to remember point number two, which is that the risk assessment must address the business goals of the organization and provide them with a real vision of how to proceed in the future to reduce their risk. So many “risk assessments” I have seen in the last 18 months seem to be little more than vulnerability assessments with some tiny bits of policy review and analysis wrapped around them.

Organizations need to get a better understanding of existing methodologies for risk assessment in order to make smarter selections in terms of vendor offerings. I think too many organizations are making their selection based on price and many times, as in life, “you get what you pay for.”

Make sure when vendors talk to you about risk assessment that you get to see sample reports, that you feel that the assessment is at a high enough level to give you real vision and value and that the results are not just findings, but real-world strategies and tactics for today and tomorrow. Otherwise, you are likely going to get much less value for your investment, and much less return on what can be an exteremely powerful tool for the future of your organization.

The BBC finally validated what security teams around the world have been saying for a couple of years – home user machine security counts too. In a recent test by the BBC news team, they used a honeypot to emulate a home user system with a high-speed connection. What they found is likely not surprising to security folks, but it is likely eye opening to the common user and management.

The BBC team set up the honeypot repeatedly over a 24 hour period. During that time, the PC was attacked 53 times from the Internet! The breakdown of the attacks they identified were as follows:

1 attempted buffer overflow
2 port scans
14 worm attacks
36 RPC-type attempts to Trojan the machine

This goes right along with the effects MSI has observed when we have done the same thing with our honeypots. These are real numbers, and in some cases, may even be low. Our common attacks from exposed honeypot systems often show higher levels of attack than this, and include hundreds of spam email probes, repeated worm assaults against web systems, scans for bad PHP and Horde Framework files and all sorts of other noise.

The reality is that attackers and automated assaults like Bots, Trojans and worms have made even the home user network neighborhoods dangerous places to hang out. Without the proper safeguards and security mechanisms, home user systems are in serious danger. Attackers will plunder them for identity data, leverage them to gain access to corporate environments and turn them into components of ever-increasing Bot-nets. Until home users begin to make better security decisions, vendors begin to integrate deeper security into their computing products and consumers begin to care about security in the way they spend their currency, it is very likely that home systems will remain little more than sitting ducks.

For the last several months, news has been coming from the various security vendors that attacker focus has shifted away from banks and other financial institutions to the credit unions. The attackers probably assume that credit unions are an easier target than the banks. In our experience this is simply not true. Though credit unions do have risks, they do not seem to be larger than banks and other financial organizations.

Primarily, credit unions face three key areas of risk by attackers today, in terms of information security. These risks are discussed below:

1) Network, application or database compromises – This is the most common form of attack when we think of information security in relation to computer data. The fears here are that an attacker could exploit a weakness in our computer systems, networks or applications and steal important member/customer data that they could use for fraud or identity theft. Common attacks include penetration of the Internet exposed network, application security issues like SQL injection or the introduction of malware/spyware into the the user’s systems to gain illicit access. To defend against these attacks credit unions should be performing ongoing security testing, using detection and prevention technologies like firewalls, IDS/IPS, honeypots, etc. They should also have strong security policies, hardy authentication, great anti-virus/malware tools and excellent patching mechanisms. These are the primary steps for protecting the electronic systems of a credit union against compromise.

2) Physical security compromises – These are the often forgotten security issues, but a breech of physical security is often among the most devastating of attacks. Items like unshredded member data, identify information, loan applications, checks or the like making their way into dumpsters is a common cause. Attackers using combinations of physical attacks and social engineering to install hardware devices on the network, gain access to sensitive areas or other forms of attack are also common. Credit unions are used to protecting themselves from outright robbery and theft, but the subtle methods of cyber-attackers leveraging the physical realm is often beyond their existing vision of security. The keys here are to have good processes for managing physical assets in the computing environment, having good employee awareness of security procedures and performing assessments to know where your weak points lie so that you can address them. Awareness is the primary tool here, as employee of the credit union must have good procedures and remain ever vigilant against breeches of these procedures and protocols. They must understand what data is confidential, and how it is to be handled, stored and discarded. Often, a risk assessment is an excellent tool for identifying issues around physical security and document handling. Credit unions would be wise to pursue a risk assessment as soon as possible, as it is has also recently become regulatory requirement.

3) Social engineering compromises – Social engineering attacks are probably the most common form of attack credit unions face. Social engineers often use trickery, deceit and trust to gain access to information that, at the time, may seem small or insignificant, but may lead to compromise on a wide scale. Social engineers may be overt, asking tellers for identify information or using phone calls to ask for passwords, or they may be subtle – like leaving CDs and USB keys in the parking lot that Trojan machines when used. No matter what form of social engineering the attacker chooses, the best defense is employee policies and awareness. Credit unions must make sure that each and every employee is aware of their security policies and the processes used to protect the environment from compromise. They must understand the risks, the current techniques in use by attackers and have a means of comfortably reporting suspicious behaviors. Only then will credit unions be well protected against social engineering.

Credit unions may be getting more scans against their firewalls and IDS/IPS systems now than banks, but the majority of credit unions are fairly well secured against Internet attacks thanks to the years of media attention and regulatory requirements. Obviously, some improvements could be made – but that is true for almost all organizations. Credit unions taking information security seriously should examine their current security posture, ensure that, at a minimum, they are performing the above tasks and then work toward identifying a means to improve. Attackers will follow money, and as such they will remain focused on credit unions, banks and other financial institutions for some time to come.

Overall, though, credit union members have no reason to feel that they are at increased risk just because they belong to a credit union. In our opinion, the risks to the average consumer show little difference between using a bank or a credit union. The average consumer risks far more by shopping using their credit cards or not using a shredder for their home trash than by choosing to do business with either financial institution, be it bank or credit union.

I just heard from a client, one Mr. BW, we shall call him, that he has a smart new use for HoneyPoint Security Server in his organization. In addition to using it as designed, to capture emerging internal threats, Mr. BW has found a way to make use of HoneyPoint’s emulated web server to catch and capture malware and spyware inside his organization!

He came up with the idea of using HPSS, in conjunction with the Bleeding Snort Rule Set for Malware. He extracted the appropriate black hole DNS records and placed them on his internal DNS server. But this simply black holed the systems, and broke the connections – but did not give him the information of what the malware was seeking, passing or otherwise communicating. Thus, he changed the black hole DNS entries to point to a HoneyPoint emulated web server!

Now, when known malware triggers a bad DNS entry, the malware is redirected to the HoneyPoint. This not only alerts Mr. BW to the presence of the malware and the location of the infected PC – but – it also gives him insight into exactly what the malware is doing, what information is being transmitted and how extensive the damage may be.

Mr. BW says this gives him a unique capability to communicate the overall risks of the malware and a new tool in helping to protect his organization.

Our thanks to Mr. BW for his feedback and insight! Congrats on the forward thinking and on the adaptation of the tool to your needs!

They put an exploit in, they put a patch out, they put an exploit in and users turn themselves about… You get the idea (sorry, I know it’s bad)…

IE users (and Microsoft) are having a particularly bad couple of weeks. First the VML issue became critical and widespread, with all the associated user confusion of the work-arounds and such. Microsoft then releases an out-of-cycle patch, only to be one-upped by attackers who almost immediately release a reworking of a formerly DoS attack into yet another remote code execution bug in IE.

As with VML, this new “old” bug is likely to be widespread and adopted into various bot and browser vulnerability frameworks. Basically, continuing to make it even more unsafe for users to browse the web at large than before…Blah, Blah, Blah… Just as before, repeat – because apparently “that’s what it’s all about”.

😉

In the meantime, while we wait on patches for this latest IE exploit, do the usual. Try and educate users about safer browsing choices, reinforce the idea of enclave computing with your management team, harden your browsing environment as much as possible and make sure IDS/IPS signatures and AV/Spyware signatures are up to date.

Oh, and if you have time, learn the hokey pokey dance. It’s helpful at weddings and looks like it might be a good skill to have for the coming months!

For several days we have been monitoring the explosion of the VML 0-day for Internet Explorer. It has become clear that this is a significant exploit.

Attackers began almost immediately to spread and improve the exploit once it was published. It was quickly included into several vulnerability and exploit tools. It took a suprisingly short amount of time for the incidents to begin to pop up around the Net.

The fact that Outlook is also vulnerable added to the fuel of the underground, as attackers with all kinds of motives began their assaults. They continue, even as I write this.

The exploit is ugly and dangerous. It has multiple attack vectors, including web and email, and attackers have refined the code until they now have the capability to do proper version checking and adapt the exploit to a variety of platforms.

Currently, some AV vendors have been less successful in defending against this problem than others. Many AV vendors are working hard to keep up with the ever changing set of binaries that the exploit examples download after the exploit runs. We all know this is admirable, but a losing battle. Truly resourceful attackers will grab code that is in no database, and even basic attackers will be able to modify existing tools to bypass the rudimentary checks many vendors are using.

In the meantime, the workaround is continuing to be used and refined as well. If you can get by without VML, unregister the DLL to protect yourself and your organization. Security teams should be making this decision quickly, as it may already be too late.

The last we heard, Microsoft is scheduled to release the official patch on Oct. 10. This means there is still plenty time for attackers to identify, target and exploit users around the world. The work around may be the best defense until the patch becomes available.

Stay tuned to your normal security intelligence sources for more information as it becomes available. Check out WatchDog if you are looking for such a source. It is available FREE from http://www.microsolved.com/watchdog

In many of the conversations I have been having lately with InfoSec managers, some of them seem to have forgotten some of the basics of our relationship with attackers. They seem to have forgotten some of the basic tenents of security and they certainly don’t seem to be aware of Murphy’s Law.

So, let’s review a couple of items – just for refresher.

The first item is that attackers control the pace, not defenders. They are in control of when attacks occur, where they occur and how serious they are. Now we, as defenders, have some capabilities here to try and make sure we have minimized the impact of these incidents – but we have NO CONTROL over the timing, pace or location. Those items belong to the attacker.

Second, attackers will focus on your weaknesses, not your strengths. That is simply what smart attackers do. If you build all of your defenses and post your armies of cyber soldiers to brace for a full frontal assault, it is likely that a smart attacker will flank you. This is elementary in warfare, and it is a real and vital part of InfoSec too. You have to allow for defenses that embrace your assets and not just protect the obvious issues. You have to be ready for defending the subtle assets and locations too. Gone are the days, if they ever really existed, of attackers impaling themselves on your firewall and IDS/IPS in mass. Today, attackers are more subtle, more evasive and target things deeper in your territory. Things like users, client-side vulnerabilities and remote access points are juicy targets for today’s attacker.

As for Murphy, InfoSec managers need to remember, attackers will exploit timing issues without concern. They will leverage the fact that you are down a headcount, that your entire staff is at a week of training, that your budget does not have room for the sudden purchase of a security tool to combat a new threat. Attacks will come at the worst possible moment, so you might as well plan for them. Got a merger coming up, or an important period of business in the run for the end of the year? If so, it would be wise to ensure you preserve some resources for possible incidents and attacks. Murphy says they are just likely to happen when you need them least.

Again, I know these seem pretty basic, but they are truths of security and defense. They are universal, uncaring and painful if you have to learn them the hard way. So, build them into your plans and be ready to explain them to other management. The more you study them up front, the less they can harm you down the road.

Ruby on Rails has seen wide adoption since its introduction. It is a very powerful platform for rapid prototyping and develppment of web-based applications ranging from the trivial to the complex. Up until now, it was also thought to be very secure.

Now, all of that may change. As I write this, a very serious vulnerability has been identified in RoR. While the Rails management team have released a patch to RoR that they have termed a “mandatory upgrade” , it should be considered very likely that some group of attackers may have already been aware of the issue. As such, careful inspection of logs and such should be performed for any and all RoR applications.

Given the wide range of applications deployed on RoR, organizations using it should be paying very careful attention and applying the upgrade as soon as possible.

Attackers have long focused on web applications as a primary target. We have seen wide scale attacks against many other web platforms from PHP to the Horde framework. Now some of that attention may shift to RoR. I, for one, hope it can handle the pressure…