Prep for Election Day

With election day on tomorrow’s dawn, now might be a good time to prep yourself for the coming tasks.

1) Make sure you have your ID, driver’s license or other documentation that may be required to vote in your state.

2) Take the time to prepare and familiarize yourself with the issues. There are several sites sorted by states that cover the various issues. Use a search engine to locate your specific issues and races.

3) Be prepared for weather issues, traffic, long lines and other significant problems. Take enough time to allow for the task and any snafus that might arise. Bring a book, a bottle of water and your patience.

4) Forget “testing the security” if that is your deal. It will only cause problems for you, others and the board of elections. Play around in the voting booth and you might end up spending some time as a guest of your state. Forget the e-voting media and press and just make your voice heard with a proper vote. Let the voting officials handle the rest.

Most of all, just vote. It is the single most important duty we have as an American. So, make your choices, select your candidate and do your patriotic duty. Using your voice is the finest way to honor the memory and sacrifice of all those who made it possible!

Web Application Targeting on the Rise

Recently, attacks on web applications have been on the rise, and there is good evidence that exploitation through SQL injection of web applications has brought about the tremendous surge in botnet infected machines. The focus of such attacks should result in us asking ourselves if we are at risk. If you have a web application it is quite possible that you are, and could likely be a target.

One of the fundamental best practices for being sure you don’t get compromised through a web application is to have strict input validation. What do I mean by “strict input validation?” Essentially, this means filtering the input to ensure the data presented by the user to the page does not contain characters that the application could mistake for code to be executed. Using input validation protects your site from executing arbitrary and malicious code that compromises your system.

Another big thing to consider is error control, often times SQL errors are displayed out in the open, or a directory listing is shown. A simple Google search for these error codes represent low-hanging fruit for a malicious attacker, allowing them to identify your website as a target. I would encourage everyone to take a close look at your web applications and make sure you are protected against this increased attacker focus.

HoneyPoint Personal Edition Key Change in Upcoming Versions

Please be aware that new versions of HPPE in the works will be using a new key mechanism. The current key mechanism appears to have fallen prey to piracy and a key has been identified in several “WAREZ” distribution sites. It appears that the current key that was leaked was made public after the software was awarded as a prize at a local public IT event. We have received several reports of web sites hosting the current version of the software with the leaked key and of several torrents floating about the Internet.

Thanks to those who reported the issue and who alerted us to the presence of the leaked key. We urge any illicit users to register their software and purchase a valid copy from our site here. Your continued support of the product will allow us to continue to improve the product.

While software piracy is regrettable, we of all people, know that essentially any type of software license can be defeated. We have and will continue to make our software licenses as convenient for our customers as possible. In our opinion, ease of use is key!

Please note that HPSS keys are unaffected as the product is licensed using an entirely different mechanism that is host specific. HPPE licenses depend solely on a custom generated numeric key sequence.

Have an Application or a Device on the Market — We Will Test Its Security Posture

Just a reminder about our lab services for those organizations that may be interested. Part of what has made MSI famous over the years is the extensive work we have done around application and device security. Our lab has tested everything from traditional software to ultra-modern web applications and all kinds of hardware from appliance firewall and server loads to bio-metric systems, check scanners and, of course, the voting systems!

In the past we have served as security testing labs for operating systems, appliance applications, consumer electronics, various financial products and a ton of consumer-facing software tools. Many vendors have chosen us as partners for application/device-based risk assessments, product testing, vulnerability management and penetration testing. We have even done some heavy testing of data destruction systems in conjunction with another lab who was testing data recovery capabilities.

Our lab has also been used by Information Security and ITWorld magazines for reviews, technology analysis and vendor evaluations. We have extensive experience in reviewing products for client companies, performing/managing vendor product bake-offs and leveraging our publicly acclaimed processes for proactive threat modeling to help companies spend their IT and infosec budget dollars as wisely as possible.

Our team loves to learn about, play with and exploit new technologies and products. They are continually involved in analysis of various products and projects. We are now accepting a few new projects for lab review and testing for the 4th quarter, so if you or your company are interested in establishing security as a differentiator for your product or having your new web-application branded with our labs SecureAssure logo, get in touch with an account executive as soon as possible. We only accept a few new products every quarter due to our schedule and the intensity of our process and those slots usually fill up very very quickly.

E-Voting Follow Up

I think the presentation at TechColumbus went well. The crowd seemed into it and their questions, comments and feedback were good. Sorry to the person I had to shutdown during the talk – but we had a time limit and such for the presentation and we had to keep from getting on a tangent.

Overall the e-voting summary was that yes, the systems are broken. Yes, they have vulnerabilities. But, we know what many of them are and we know what many of the exploits look like when performed. The Secretary of State has implemented process controls and new techniques for monitoring and detection of many of the attacks that EVEREST identified. Even though the system might be less than perfect – YOU SHOULD STILL GET OUT AND VOTE.

Thanks to Terry Dick, the Ohio Secretary of State’s Office, TechColumbus, Platform Labs, Mike Krippendorf and David Garcia for the help with the presentation. Special thanks to the rest of the EVEREST team, without everyone’s dedication to the cause, it would not have been as successful as it was. Extra special thanks to those who attended, without you guys, we are just strangers talking to ourselves in a dark room!

Here’s hoping everyone has a nice weekend.

Microsoft Patches Now Have an Exploitability Rating

Microsoft patches now include a new exploitability index. This new rating attempts to quantify when/if an exploit is likely to become available for a given vulnerability. The rating also attempts to take into consideration how stable a given exploit is likely to be.

Personally, I think this is a good idea, especially if they keep their methods for rating issues consistent and transparent. Already, a number of vendors have said that they will be adding support for the new index value in their tools and software. As might be expected, reaction has been mixed from the community, though, I have yet to see any response that included how such information could be truly harmful.

You can read Microsoft’s published information here.

I hope more vendors embrace this seemingly small detail. I think it is helpful for more than a few organizations overwhelmed by patch cycles. It may not be the “holy grail of patch risk”, but it is likely better than what we have now.

How does your organization plan to use this new information, if at all? Drop us a comment and let us know!

Why Replacing Internal NIDS with HoneyPoint is Critical to Your Organization

We are in a new age of information security. The primary threats to our critical data assets are well within the firewalls and layered architectures of the degenerative “perimeter”. Attackers can and will leap your firewalls, tunnel through your DMZs and trick your users into being the gateway to attack. The idea of the walled castle as a form of defense is destroyed and no longer serves anyone well.

With 55% of all attacks that cause financial damages to organizations originating internally, it makes sense that organizations change their focus to internal prevention, detection and response. But using a “false positive generator” like Snort!, Proventia or other NIDS approach is just madness. These mechanisms are so fraught with bad data when focused on the typical internal network that applying any attention to them at all is a huge waste of resources. Of course, the vendors will respond with their magic phrases – “tuning” and “managed service” both of which are just marketing speak for “spend more time and resources that you already don’t have on making our tool actually useful”. Don’t believe me, just ask them about applying their tool to a complex internal environment. Our polls, interviews and questions to users of these technology showed immense amounts of time, money and human resources being applied to keeping signatures up to date, tweaking filters and rules to eliminate false positives and spending HUGE amounts of security team time to chase ghosts and sort out useful events from the noise.

Our initial metrics, as we discussed previously showed that we could cut those resource requirements by 60-90% using a different approach. By leveraging the power of HoneyPoints, their deploy and forget architecture and their lack of false positives your organization can reap the reward of better security with less time, money and work. By combining HoneyPoint Security Server and an appropriate log monitoring tool (like OSSEC), organizations have been able to greatly simplify their deployments, reduce their costs and increase their abilities to focus on the security events that matter. Many have relegated their NIDS deployments at the perimeters to being another source of forensic data to be used along with syslog server data, file system analysis and other data sources compiled to provide evidence when a true incident occurs. NIDS at the perimeters have their value here and being a part of solution as a forensic tool makes them effective when needed, but prevents the “attention overload” that they require when used as a data source on a daily basis.

Detection of attackers in your environment IS CRITICAL. But the way you go about it has to make sense from both a security and manageability standpoint. NIDS has proven to be an ineffective solution in terms of allowing organizations with average resources to succeed. There is a way forward. That way is to change the way we think about information security. HoneyPoint Security Server and MicroSolved can help your organization do just that!

Check out http://www.microsolved.com/honeypoint/ for more information, or give us a call and we will be happy to explain how it works!

Please note: Snort! and Proventia are trademarks of their respective companies. They are great tools when applied to appropriate problems, but in the case of internal network security – we just have a better way! 🙂

3 Reasons Why Internet Voting is a Bad Idea

One of the questions I get asked the most when I speak on electronic voting is why voting is not done over the Internet. While I can clearly understand the idea of online voting being easy and efficient, I wanted to take a moment and give you the three biggest reasons why I think it is a bad idea, at least currently.

1. End Point Security. Voting online would mean that we would allow users to come into an online portal and cast their respective votes. The problem is that we have zero control over the security of the PC doing the voting. Your machine could be under the control of an attacker who could perform any myriad of attacks against you or the voting system. It would be trivial for an attacker who has gained control of your machine to both know how you voted and to modify your vote in real time. Everything from the simple to the sophisticated is within the realm of likely threats against home machines, for proof just look at the number and rates of bot-net infections. Imagine the chaos that could result from voting on compromised systems on a wide scale. The number of variables in this part of the equation alone is enough to give you nightmares.

2. Anonymity. The very processes that would be required to secure and authenticate the voter to the online voting system would also greatly impact their ability to remain anonymous. In order to verify the online identity of the voter, ensure that they only vote once and secure the voting session would require the system to correctly identify the voter against a database and then allow the voter to vote online. Such identification would involve a plethora of logged events and data records. Each of those log entries and data records could be compiled to help an attacker, especially an insider, identify particular voters and perhaps even isolate their vote cast. This has shown to be true with time stamps of paper trails in the current e-voting systems and would be only easier to accomplish with purely digital data.

3. Denial of Service Attacks. This is a severe issue. DoS attacks are trivial to perform these days, even against large scale systems and those with advanced capabilities. The prevalence and ease of bot-net attacks reduce the complexity of shutting down a site to the trivial level. If entire nation’s networks can be knocked off the net, then what chance would a voting portal have? Given the sensitivity, time requirements and public confidence that is needed in the electoral process, any successful denial of service attack against the voting system would be likely to cause chaos. In worst case scenarios, the entire electoral process could be disrupted or forced back to the alternative measures anyway.

In addition to these 3 reasons, many others exist. Sure, there are solutions for some of the problems – but they each range in scale from small to immense. While some countries have worked on or even adopted online voting, it continues to be a bad idea, in my opinion for the United States. The added complexity, cost and security issues certainly raise the idea well beyond the level of current workability. Cost alone is a killer given our current state of the economy, in my opinion.

So, the bottom line is that our current e-voting processes are not perfect. They do leave a lot to be desired, but work is being done in this area. Online voting, however, faces significant issues before it could even be considered as a relatively workable idea.

If you are interested in hearing more about e-voting, I will be presenting this Friday at TechColumbus on the issue, along with another member of the EVEREST team from the Ohio Secretary of State’s office. You can learn more and sign up at: http://www.techcolumbus.org/en/cev/314

HPSS And OSSEC

I’d like to go over some of the tools that we mention on the blog. The first one I’d like to take a look at is OSSEC. You may have heard of us talking about it before, we mentioned it a few days ago. That was in relation to HoneyPoints and using OSSEC as another layer of your “defense in depth” strategy. I’ll explain what it does, and how it can help you.

First of all, what is OSSEC? OSSEC is an acronym for “Open Source Host-based Intrusion Detection System”. From the name you can see it’s a Host-based Intrusion Detection System (HIDS). As a HIDS it has the capability to do log analysis, integrity checking, Windows registry monitoring (and event log), rootkit detection, real-time alerting and active response against malicious hosts. It can be run locally, or as a centralized system with agents running on hosts.

So how does OSSEC relate to HoneyPoint? Well they both watch different things, and complement each other. While HoneyPoints are psuedo services and capture traffic from them, OSSEC watches real services for probes and compromises. It does this largely by a system of log analysis. I won’t go into it deeply, but the log analysis rules are very configurable, chainable, and fairly easy to write for anyone that knows regex and has a familiarity of basic scripting language.

With OSSEC’s active monitoring, it’s possible for the host to dynamically write firewall rules to block that host. Similar to HoneyPoints Plugin interface, with which you could also use to write a plugin to do that. You could even use OSSEC to watch your HoneyPoint Console syslogs and integrate HoneyPoint Console triggers with its own active response rules, to centralize blocking of hosts between HPSS and OSSEC.

As you can see, OSSEC can work quite nicely with HoneyPoint Security Server as part of a “defense in depth” strategy. There’s no single tool to “rule them all”, so to speak, so it’s important to watch from multiple perspectives! If you want to check out OSSEC, you can visit www.ossec.net.

Port Knocking and SPA – Thoughts

A colleague of mine pointed me to an article on Port Knocking, more specifically, Single Packet Authorization. I wasn’t too familiar with either but once I started reading, some thoughts came to mind. Does this look far to cumbersome and “pain in the butt” to implement for such a small gain to anyone else? This is just another method of implementing the doomed “security by obscurity”.
First off, Port Knocking “is a method of externally opening ports on a firewall by generating a connection attempt on a set of prespecified closed ports.” [1] Single Packet Authorization is similar, but requires only one encrypted packet. While this may impress some people with it’s technical savvy, this solution should be thoroughly evaluated before implementing. As far as enterprise usability goes – limited at best. Talking amongst ourselves here we did think of one implementation that would actually be useful. That is to prevent your ISP from knowing you’re hosting a service without having to create extensive black or white lists. You could host an ftp server for example without the port ever showing as open to an overly intrusive ISP. Of course we do not condone the breaking of any agreements with an ISP.
However, for enterprise environments Port Knocking and Single Packet Authorization are in my opinion no way a replacement for good security practices These include keeping the service up to date with any patches/updates provided by the vendor. Be aware of any newly developed or developing threats to the service you’re hosting. Implement proper ACLs at the firewall. Block all of Eastern Asia from accessing your SSH service if need be. Use VPN clients. This is critical, there’s no real reason to have remote access ports opened without protection. Use VPN clients. Just about every enterprise firewall comes with some sort of VPN option. Last but not least, do not forget the importance of a strong password policy. Brute force attacks really become a non issue with a complicated enough password.
In conclusion, PK and SPA sound good in practice, and implemented as part of a greater defense in depth solution could work; otherwise, stand alone PK and SPA in my opinion are less than ideal.

[1] http://en.wikipedia.org/wiki/Port_knocking