I got a lot of response from folks about my last cheat sheet post. Here is another one that many folks might find useful.

This one, from Microsoft, describes quick references for the Microsoft Web App Security Framework. This is a pretty useful sheet and one that our techs use a lot.

I also find this one for Nessus and Nmap to be pretty useful.

I found this one for you CISSP study folk.

This one for PMP study folk.

And, lastly, for all the new waxers of armchair economics, this one about sub-prime mortgages…

OK,OK, I could not resist this one, THE INTERACTIVE SIX DEGREES OF KEVIN BACON CHEAT SHEET!

Hope you enjoy these, and now back to your regularly scheduled infosec blogs… 🙂

Our tech lab reviews several financial applications every year from a variety of vendors that are focused on the financial institution market space. The majority of these applications perform poorly to some extent in either security and/or usability. Here are three key tips for vendors to keep in mind when they or their clients ask us to do an assessment of their application.

1. Make sure the application actually works as it would in a production environment. Make sure it is reasonable in terms of performance. The idea of performing our lab assessment is to model risks in a real world simulation. Thus, if the system is not configured and working as it would in a real deployment, then the validity of the test is poor. Many of the applications we test simply do not function as expected. Many times, their performance is so slow and horrible that it impacts the availability metric. Basically, by the time it is submitted for the complete application assessment or risk assessment, it should work and be installed in a QA environment just as it would be in production. If there are any variances, be prepared with a document that explains them and their anticipated effects. Be ready to discuss and defend your assertions with a team of deeply technical engineers.

2. Do the basics. Make sure you meet an established baseline like PCI, ISO or some other basic security measure. That means ensuring that controls are in use to provide for confidentiality, integrity and availability. That means that you are protecting the data properly during transit, storage and processing. That means that you and/or your client have an idea about how to provide preventative, detective and responsive capabilities around your product. Make sure your documentation clearly explains any security assumptions or add-on products required.

3. Be ready to handle issues. If/When we find a security issue, be it overflows, input problems, and/or best practice variances, be ready to mitigate the issue and submit a fix. Many times it takes months for vendors to handle the issues we find and this is certainly NOT good for their relationship with the client. Almost every full assessment our lab conducts involves some kind of deployment timeline and crunch from the customer. Nothing seems to go worse for vendors whose products we test as when an issue is found and they become unresponsive to us and/or their client. Seriously, JUST DON’T DO THIS. Be prepared to apply resources to fix issues when we test the application. Very few applications (less than 2%) pass through the lab process without some sort of issue. This is NOT a basic process, it is a seriously deep, complex and heavily leveraged process for finding holes and measuring impact. Be prepared.

I hope this post helps both clients and vendors be better prepared for their testing. I think it gives the basic ideas for the approaches that we know do not work. We really want your applications to be secure, thus the level of detail we apply. Let us know if you have any questions. We are also about to open the lab registration window for 1Q09, so if you have applications you would like tested, let us know and we will try and get them on the schedule.

One of the best tools that the technicians at MSI rave about is a series of information security “cheat sheets” that they keep around the lab. These small, easy to view posters make quick visual references for common commands, tool parameters, etc. They can be an excellent source for remembering those specific commands or settings that always seem to elude techs or that are just so convoluted that you have to look them up anyway.

The MSI techs suggest checking out this site for a whole library of these tools.

If there are other sites out there that your team uses to obtain these helpful posters, please reply with a comment.

If you have made your own cheat sheets, please send us a link if they are public and we will post the ones we compile at a later date. Thanks for reading!

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!

The broadband caps proposed by Comcast and other home ISPs would mean that consumers would now be paying for excessive traffic from their networks, even when malware or bot-nets caused the traffic. Much media attention has been paid to the effect of traffic from spam and video ads used in normal web pages, but little has been said about the effect on consumers that malware infection could now have.

Imagine a simple malware infection that sends email. That infected machine could send millions of emails a month, easily breaching the modest bandwidth limits that some are proposing. How will the average consumer respond when they get warnings and then large bills from their network ISP for traffic that they did not cause? Imagine the help desk calls, irate customers and the increased costs of handling such incidents. How will the average help desk technician handle claims that infected systems caused the excess traffic?How will courts handle the cases when the consumer refuses to pay these charges and the ISP pursues their clients for the money?

Attackers are the real winners here, at least those interested in causing chaos. Effective attacks to cause financial damages and ISP cutoff against a known/focused target become all that much easier to perform. If you hate your neighbor and her barking dog, then you get her machine infected with malware and cause her to get a huge bill from her cable company. Do this enough and you can damage her credit, get her cut off from the Internet and maybe even interfere with her ability to earn a living (especially if she is a web worker). Heck, malware isn’t the only way – break into her wireless network or find it open to start with – and you have the perfect entry point for making her “iLife” a true nightmare.

Sure, some folks say these risks already exist without the added pressures of ISP bandwidth caps. They are right, they do. Some folks also say that these threats may make average consumers pay more attention to security. I think they are wrong, this will be just another item on a long list of ignored and forgotten “bad things” that happen to “other people”. However, I do think that these attacks should be a serious concern for the ISPs implementing the caps. The ISPs seem to be sharing a primary of claim that they are adding these caps due to bandwidth issues and the costs required to handle the current and future traffic. Yet, I would suggest that bandwidth caps are very likely to raise their support and account management costs exponentially – which could mean that they are shooting themselves in the foot.

Bandwidth caps are a bad idea for a variety of reasons (including stifling innovation), but they play directly into attacker hands and lend attackers a new spin on how to cause damage and chaos. In the last few weeks, much has been made of the recent growth in bot-net infected systems. Experts point to a nearly 400% increase over the summer months alone. Imagine the chaos and issues that could stem from calculated campaigns that wrangle those bot-net infected machines into breaking the boundaries of their ISP. Maybe bot herders would even change from holding end users hostage to targeting ISPs with bandwidth cap breaking storms that would trigger massive client notifications, calls to technical support and account management systems. Maybe attackers could figure out a way to use bot-net infected systems to cause “human customer denial-of-service” attacks against cable companies. I am certainly not rooting for such a thing, but it seems plausible given the current state of infected systems.

I just don’t see a positive for anyone coming from these ideas. I don’t see how they aid the consumer. I see how they could be used to harm both the consumer and the ISP. I see how attackers could leverage the change in multiple ways – given than many are extensions of existing issues. Generally, I just fail to see an upside. I find it hard to believe that consumers will be thrilled about paying for illicit traffic that they will argue they did not create and I can’t see the courts doing much to force them to pay for that traffic. I guess only time will tell – but it seems to me that in this game – everyone loses…

Abstract:

This presentation will explain several techniques that have successfully been used to help upper management understand the information security initiative in several organizations. Overall strategies and specific tactics for gaining upper management support will be identified. The audience can use these techniques to gain, maintain and ensure rapport with upper management, establish and reinforce the value of the security team and to demonstrate the value of including the security team in business operational decisions and planning.

This virtual event will be held Wednesday, April 30^th 2008 at 4pm Eastern time. You can get access to a PDF of the slides and the phone number and passcode for the audio portion by sending an RSVP email to info@microsolved.com.

For those unable to attend, the slides and an MP3 of the audio portion will be made available following the presentation.