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…

I have been hinting that something big was coming for a few weeks now, and it is finally time to talk about it.

The big news is the release of MSI’s first enterprise security product – HoneyPoint.

HoneyPoint is designed as a direct response to the pain that I have been hearing about from network security folks for several years now. That pain is the general failure of network-based Intrusion Detection and Intrusion Prevention systems (IDS/IPS) to live up to the hype that surrounds them. Over the years, the idea of IDS has grown from a simple system of matching packets against a few signatures to a much larger beast.

Today’s IDS and IPS systems are broken. Most depend on signatures (be that against network packets or system & application logs). They compare the current traffic or events against that signature base and make a decision about the malicious intent of the traffic or events they are seeing. This was a great idea, to be sure, but it has largely failed to reach the promises vendors have been making for nearly a decade. There are simply too many signatures, too many nuances of traffic, networks have become too complex for effective IDS management and there is too much noise on modern networks for the signature-based approach to remain fully viable.

Now, before every IDS/IPS vendor in the world calls to tell me about their latest technology or technique to auto-tune, establish relevant baselines or use traffic patterns instead of signatures, I want to simply say this. Great! Good for you. But, I am not interested in hearing much about it. The current idea of IDS/IPS simply does not work. It is broken. Period.

Another reason why I say that is this – I have spent the last year talking directly with IDS/IPS users and hearing about their pain. They are spending way too much time tuning, updating and managing their IDS/IPS solutions. Even those that outsource their management, say they still spend way too much time working on false positive events or tracing issues that turn out to be nothing or worst of all, fighting against bot-nets, client side exploits, zero-day issues and other items that their detection systems failed to identify or stop. To put it simply, as one person did for me, they are “spending more time on managing the IDS than they are on responding to the 10K and more alerts it gives them each day.” To add insult to injury, of these 10K alerts – the majority of them turn out to be false positives.

Since threats are evolving and pushing into the organization at a much deeper level than the perimeter, and every trade magazine and security visionary is telling security teams to switch to enclave computing and begin to take an asset-centric approach to security, that is exactly what security professionals are doing. The problem is, they are finding that traditional IDS/IPS solutions are really not meeting the needs of securing the internal network in a meaningful way.

Thus, the paradigm shift that is HoneyPoint. The idea is an old one. The implementation is new. The idea of honeypots goes back a long way. They are essentially based upon the idea that if you create artifical systems or services on your network, an attacker will not know if what they see is real. The idea is that in order to determine what is real, they will have to probe and attack all of the visible targets. In doing so, they will, in more cases than not, probe a honeypot – thus alerting security folks to their presence. Obviously, the more honeypots, the higher the likelihood of their being probed instead of a real system.

This is the basis for HoneyPoint. We use it to make our systems offer services across the network that appear to be vanilla and homogenous. Imagine a big 10×10 grid of light sockets. If you had a light bulb and were asked to screw it into some of the sockets in the board, but some of the sockets were real and would light the bulb, while others would set off an alarm – how would you go about identifying which ones were real and which were alarms? You might carefully examine them, but if they all look similiar, the only way to know would be to try them.

That is exactly what we do with HoneyPoint. We dialate ports across our systems with similiar appearing services, and then wait for attackers to try and figure out which ones are real and which ones are HoneyPoints. Just by doing what attackers do – that is, probing the network and services they find – they fall into our trap and alert us to their presence. Once identified, they can be quickly isolated and shut down by network security staff.

The most beautiful part of all of this is the lack of false positives and signatures. Since the services offered by the HoneyPoints are not real, there is absolutely no reason at all for anyone to be using them. That means that ALL TRANSACTIONS WITH A HONEYPOINT ARE REAL EVENTS. Since the HoneyPoints key in on the idea that a transaction has occurred, and not what it was; they have no need for signatures (thus, no need to update and tune them). They simply capture the traffic they see, identify the source and alert the console of the event. Simple. Easy. No muss, no fuss – no additional management. The alerts from the console system can then be handled by the security team as an incident.

Alerts can be delivered via email, SMS (with a gateway), syslog or Windows Event logs. The console and HoneyPoints run on Win32, Linux/UNIX and OS X. Given their flexability, they can emulate thousands of services ranging from complex HTTP applications to RFC compliant implementations of your chosen mail platform. The variations are as flexible and endless as your imagination.

The HoneyPoint solution is built upon the idea of “deploy and forget.” HoneyPoints need only be installed and configured one time (leaving more time for vacations). They then operate as services or daemons (depending on OS) and simply wait for attackers to probe them. They have miniscule file sizes and memory demands, meaning you can run thousands on an average workstation size system with little impact, should you so desire. We suggest that you deploy them across your enterprise on your existing systems. No new hardware is needed.

Take a few minutes and visit the HoneyPoint web site at: http://www.microsolved.com/honeypoint for more information. Take it for a spin by filling out the form and get your FREE 90 day trial.

I think you will quickly come to understand why we are so excited and why security teams from many of our customers are telling us we have changed the way they think about securing thier environments!

Thanks for reading and for being patient while we brought HoneyPoint to life. I think once you use it, you’ll agree – it was well worth it!

MSI is pleased to annouce that we will be moving soon to our new offices. We intend to do so in the next couple of weeks. The new building is located on the West side of Columbus and is a major upgrade for us in terms of space and useability.

Stay tuned for announcements on the new address, but the phone numbers and web presence will remain the same – of course.

Thanks for your patience the last few weeks and in the coming days while we prepare for and execute the transition. Blog entries have been and will likely be slower while we pursue the move.

Thanks to everyone who has helped make this possible and who has worked with us to prepare!