The most effective protections are all free: Use application whitelisting, click-to-play, and take away local administrator rights. If you have any questions about any of those, please ask.

On a different topic, today is the first main day of DEFCON, the big hacking convention in Las Vegas. Expect the news to be full of stories about new hacks as they are announced during presentations at DEFCON. You may have seen the announcement about how hackers can defeat the new chip-and-pin protection on credit cards. More to follow…

The post Ransomware Statistics and Expect Hacking on the News appeared first on Foster Institute.

1. Keep critical operating system and application patches up to date, especially Flash, Java, Reader, and your browsers. Updates fix security loopholes in programs. The fear of a patch causing a program to malfunction can be reduced with proper testing, performing a staged rollout, and having a rollback plan.

2. Utilize Application Whitelisting. Application whitelisting allows you to specify what programs are permitted to run, such as Microsoft Office, your accounting program, and anything else your team needs for business purposes. Because of not being on the ok list, the majority of malicious software is blocked from running. The reason most companies don’t use application whitelisting is that their IT Pros know it can be a daunting process to set up and make it work well. Therefore, we can set that up for your IT pros. Why should they need to learn something when it only needs to be done once? The upkeep can be simple from then on.

3. Reduce the number of users with Local Admin rights as much as possible. This removes a user’s ability to install programs on their computer. As a result, it greatly hinders the ability for attackers to install malicious software too.

Other than implementation, none of those cost any money. You already paid for the technology. Emphasize the importance of, and support your IT Pros, as they implement these 3 powerful controls in your network.

Wishing you a thankful week and thank you all for remembering cyber-security as part of your main strategy for successful business operations!

The post Cyber Security’s Three Essential Steps appeared first on Foster Institute.

You and your IT Pros make a list of “approved programs” such as Microsoft Word, Excel, PowerPoint, IE, Firefox, Chrome, Adobe Reader, and any other programs you use. Then your computer will refuse to run any other programs – and won’t run viruses either.

Application whitelisting won’t necessarily block Java files, and some scripts, but it will block the majority of executables. You may want to disable Java anyway.

You already own the software! Microsoft includes AppLocker with your Windows OS (Windows 7: Ultimate and Enterprise) (Windows 8.1: Enterprise Only) licenses, and application restriction policies in XP. Some commercial application whitelisting tools include Bit9 Application Control, McAfee Application Control, Lumension Application Control, and Viewfinity. Other tools, such as Kaspersky, are offering application approval to their suites. The third party tools generally can make the process of implementing and maintaining application whitelisting easier for IT Pros.

Be prepared for possible resistance from your IT Pros, but be firm. You, and your organization’s reputation, are what will be hurt the most in a breach. Don’t let them postpone. And, if they are too ambitious, then it is imperative that you “hold them back.” Tell them that whitelisting by folder and paths is “Phase 1.” This will help them build a foundation upon which they can create even more restrictive environments.

The following information goes into more details, some of it technical, so it is ok to stop here and tell your IT Pros to read this part:

Know that application whitelisting isn’t “in demand,” nor is it widespread, though it should be. As a result, application whitelisting tools and experience is somewhat limited. When you embrace this technology, you will be on the leading edge, and not the bleeding edge.

Your IT professionals can configure application whitelisting solutions in such a way that upgrades and patches are allowed to run as well without specific administrator intervention.

AppLocker cannot block older 16-bit DOS applications, Java files, and Perl scripts. Refer to Microsoft documentation for a complete list.

IT Pros are very busy and realize that the process of implementing application whitelisting can be challenging. For one thing, application whitelisting can potentially cause problems if some users are not able to run the programs they need to run if the rules aren’t configured properly. Be reassured that the following information will help you be successful.

Remember, if a security control is difficult for IT Pros to implement, then attackers can assume the control is missing and that makes attacks that would normally be blocked more attractive.

Your safety-net is the audit only mode: Know that application whitelisting tools can all operate in an “audit only” mode. That means, as you are testing your application whitelisting solution, you do not have to be concerned about generating an outage on your machines. Computers will continue to function as usual, and you will be able to preview what applications would and what applications would not have been blocked.

This “audit only” mode has two big benefits that will help you feel more comfortable when you implement application whitelisting. First, you have plenty of opportunities to be sure everything is configured before you engage the actual application whitelisting. Second, the audit mode is your “safety net” in the event that application causes a widespread outage and you need to “get everyone up and running again.” You can temporarily put the application whitelisting tool into the audit only mode – and everyone will be able to work until you resolve the problems.

The implementation of application whitelisting is simplified by wizards. The core objective of application whitelisting is to create rules that define what applications are approved to execute and which are not. Rules are what application whitelisting is all about, and the wizards can make the process much easier. But, the wizards can be evil too – tempting your IT Pros to implement too much security before the basics are handled first. Some rules are good to implement right away, other rules need to wait until a later phase.

Obviously, the first step is to create an inventory of all the applications on your systems that you will mark as “approved” applications. NEWT Professional is an example of a tool that can generate an inventory of installed applications, although there are many tools available.

First, a good strategy is for IT Pros to pick one machine, preferably a standard build that is created clean for that purpose. Then, install all the applications that any user might need to use – all the applications on this single machine. Next, use the wizards to develop a set of rules that work. You have time to repeat the modification and retesting process until you achieve the results you want and need.

PHASE 1: You can create rules based upon path and folder settings: The easiest to implement, and the least secure, way to specify what applications are allowed to execute is to specify whitelisted folders by paths on the computer. The problem with this method is that an attacker can insert a devastating.exe program into an approved folder and, in that case, the executable is allowed to run. Prohibit users from being able to write files to those folders and enforce it. Block .EXE, .COM, .DLL, and the other executables but allow users to create .LNK files.

And that’s it! You’ve increased security dramatically. Let this work for a few weeks, make adjustments where necessary, and feel comfortable that security is better than it was before.

PHASE 2: You may choose to stop after completing phase 1. If you want to add even more security, you can create rules based on software signing: With this method, you can approve programs to execute based on the company that signed the executables. For example, you may configure rules that say any executables signed by Microsoft, Adobe, etc. are allowed to execute. The idea is that attackers cannot sign the executables. Know that sometimes patches and upgrades are not signed. For example, even if you have Microsoft on your approved list, Microsoft patches may not execute properly if Microsoft didn’t sign the files. Of course, this is one of the reasons you always apply patches to a test environment, or at least a test machine, before you deploy the patches into your organization.

PHASE 3: You can create rules using hashes: A hash of a file is like a thumbprint; it identifies an exact file. Rules based on file hashes are more secure than the aforementioned methods of folder and certificate based rules, and hash based rules are also the most difficult for an IT Professional to maintain. For example, the Executable(s) for Microsoft Excel can be approved by hashes of the executables. But what happens when a patch changes those files? The executables won’t match the hash and the application will stop working. Again, if you are testing the patching process, which is so important anyway, you would catch this problem before it affected any of your users anyway. Additionally, some of the commercial tools automatically update the hashes in your rules for you based on expected patches and upgrades. Avoid feeling intimidated by the hash method – it can be very secure – but you may find that maintaining the rules may be over-burdensome.

Refer to Microsoft’s documentation of how to use GPOs to deploy the rules based on departments, roles, etc. Remember that commercial tools can help automate this entire process.

Though application whitelisting is still developing, it is mature enough to become a powerful part of your cyber-security arsenal.

Your knowledge and experiences will help other administrators too. I encourage you to post your experiences to below…

The post Stonewall, not Firewall: Use Application Whitelisting appeared first on Foster Institute.