WindowSecurity.com - Monthly Newsletter - September 2013

Welcome to the WindowSecurity.com newsletter by Richard Hicks (MCSE, MCITP:EA, MVP), Sales Engineering Director for Iron Networks. Each month we will bring you interesting and helpful information pertaining to Windows Security. We want to know what all of *you* are interested in hearing about, so please send your questions and suggestions for future newsletter content to winsec@richardhicks.com.

Editor's Corner

There are seemingly endless problems with passwords today. They can be shared, stolen, guessed, or simply be weak and ineffective. Further complicating matters is password reset mechanisms that require simple responses to easily guessed or effortlessly obtained information, such as a mother's maiden name, place of birth, school you attended, name of a pet, and so on. There's no question about it…passwords need to die, and soon. That's not likely to happen, however. Although there have been advancements made recently in the areas of strong authentication using certificates and biometrics, passwords will unfortunately be the primary mode of authentication for the foreseeable future. This month I'll explore the challenges with passwords and highlight some ways to address some of these issues.

--Rich

The Trouble with Passwords

It should be pretty clear to even the most junior security administrator that passwords are problematic. Unfortunately, like it or not, it's something we have to live with and manage effectively in order to protect our data and information. The first line of defense with regard to passwords is the domain password policy. Your corporate security policy will dictate this, and of course it will vary depending on your environment. A simple password policy for a real estate company might require a minimum password length of 8 characters and must be changed every 120 days. However, a defense contractor might require a much stronger password policy, such as a minimum of 16 characters in length, upper and lower case, one non-alphanumeric character such as a symbol, and must be changed every 60 days. Enforcing password policies is accomplished through the use of Active Directory (AD) Group Policy Objects (GPO). The password policy for a given domain is defined in the Default Domain Policy GPO under Computer Configuration | Policies | Windows Settings | Security Settings | Account Policies | Password Policy. The problem with this method, however, is that this single policy applies to all accounts in the domain. We know from experience though that not all accounts are created equal. Some accounts are granted administrative privileges on the domain, or perhaps are granted access to systems that contain highly sensitive information. Ideally we should have a separate and more stringent password policy for these privileged accounts. That's where fine-grained password policies can help.

Fine-grained password policies can be used to address this challenge. Beginning in Windows Server 2008, it is possible to define a separate password policy to specific AD accounts. This allows us to define much more strict password policies for privileged accounts in the domain. The challenge with fine-grained password policy configuration in Windows Server 2008 was that it was difficult and cumbersome to implement. It involved using ADSI Edit or PowerShell to manage, and it was most unintuitive. Beginning with Windows Server 2012, fine-grained password policies can easily be configured using the new Active Directory Administrative Center (ADAC). In the ADAC, switch to tree view and expand the System container. Right-click the Password Settings Container and choose New and Password Settings. Here you'll find all of the usual password policy settings. Make any adjustments necessary, and then click Add to assign the policy to a specific user or group as necessary.

Image

No conversation about passwords would be complete without discussing alternatives to passwords. Strong authentication using certificates and/or biometrics is a great improvement over passwords alone, but we're a long way from strong authentication being widely adopted. Wherever possible, a strong authentication mechanism should be leveraged where feasible, especially for remote access or access to highly sensitive information or systems. Strong authentication is not a panacea by any stretch of the imagination. Although it can prevent password guessing/sharing and keystroke logging, they are not immune to credential theft attacks like Pass-the-Hash. After all, biometric data ultimately is converted in to a hash at some point, so all of the mechanisms used to mitigate those attacks should still be enforced.

Another particularly troublesome issue with passwords, in my opinion, is the password reset mechanism. This is more common in the consumer space, as frequently password reset mechanism for web sites, e-mail providers, and social media sites use simple, easy to guess word or phrase, which are easily deduced or found via social media. Having a long, complex password is completely useless if you know some basic information about your potential victim. My suggestion to mitigate this risk is to use something completely random. What was your first dog's name? Let's say it was "Spot". If you knew me at all, you would know that or perhaps could find it on one of the popular social media outlets I participate in. Instead of answering with a truthful response, I would enter something completely random like "multiplicative". It's not even a name…no one would guess that! Of course the challenge is for YOU to remember it when and if the time comes that you have to use the password reset mechanism, but I find that the more nonsensical my response is, the easier it is for me to remember it. Of course writing it down, or better yet, recording it using one of many popular password vaults available is an even better idea.

Passwords will be around for many years. Our personal security and the security of our enterprise rests on the effective management of passwords today. A clear corporate security policy and effective password policy management are essential to protecting our assets. Help is on the way in the form of strong authentication with certificates and biometrics, but wide adoption of these technologies is still a few years out, in my estimation. Until then stay vigilant and guard those passwords!

Windows Server 2012 Security from End to Edge and Beyond

If you're planning to deploy Windows Server 2012 now or in the future, be sure to order your copy of Window Server 2012 Security from End to Edge and Beyond today. Written by veteran security authors Tom Shinder, Deb Shinder, and Yuri Diogenes, this book provides detailed, prescriptive guidance on how to architect, design, plan, and deploy Windows Server 2012 in a secure manner. This book covers all aspects of Windows Server 2012 security, including Active Directory and Certificate Services, Active Directory Federation Services (AD FS), Active Directory Rights Management Services (AD RMS), patch management, Hyper-V, remote access, and application, network, and cloud security.

This book is an essential reference for IT professionals and security administrators everywhere, so order now. You'll be glad you did!

Image

Click here to order your copy today!

Microsoft Security Bulletins for September 2013

For the month of September, Microsoft has released 13 security bulletins, 4 of which are rated as critical. Affected software includes all supported Microsoft client and server operating systems, as well as Microsoft Office, SharePoint Server, and Microsoft Front Page 2003. This month there was an issue with a non-security update that affected Outlook 2013 which prevented the folder pane from being displayed, forcing Microsoft to withdraw the update. More details on the update, affected versions of Outlook, and how to fix it can be found here. For more information about September's security bulletins click here.

Articles of Interest

  1. Continuing the theme of passwords in this month's WindowSecurity.com monthly newsletter, the importance of a clear and concise password management strategy is essential to providing effective protection of corporate assets. And if you think you're not affected because you are an individual or small business, think again. Everyone should have a strategy when it comes to password management. Often, passwords are all that stand between an attacker and your sensitive data, so be prepared and plan accordingly.
    http://blog.scorpionsoft.com/blog/2013/08/creating-a-password-management-strategy-as-part-of-a-game-plan.html
  2. Traditionally we've always been taught that long, complex passwords are essentially safe from cracking. However, recent events may prove that to be untrue. Recently the popular password cracking tool Haschcat was upgraded to support the cracking of passwords up to 55 characters in length. This is a giant leap from its previous limitation of 15 characters. Strong passwords (long and complex) are still an effective deterrent from things like password guessing, but this tool underscores the power of an offline attack. It is vital that security administrators protect their password databases vigilantly to mitigate these types of vulnerabilities.
    http://www.welivesecurity.com/2013/08/27/even-long-passwords-can-be-cracked-quickly-as-hashcat-app-upgrades/

  3. A recently discovered Trojan is targeting FTP clients. Malware being delivered through e-mail is targeting passwords stored in popular FTP clients like CuteFTP. If you're using this software for the transfer of sensitive data, inspect those systems closely and ensure that passwords are rotated frequently.
    http://blog.fortinet.com/Not-So-Cute-FTP-Attack/

  4. The adoption of IPv6 is essential to the future growth of the Internet. Enterprise adoption of IPv6 is important too, as the depletion of the IPv4 address space means that many regions may soon be running IPv6 only. In order to make services available to customers in these regions, IPv6 will be a requirement in the not-so-distant future. The deployment of IPv6 is not without its own security challenges, however. Often this comes in the form of changes to firewalls, Intrusion Detection and Prevention Systems (IDS/IPS), threat assessment tools, and Security Event Information Management (SEIM) databases. These challenges are not insurmountable, however, and should not be a significant deterrent to the adoption of IPv6. We overcame these same challenges when we moved from NetBEUI, AppleTalk, and IPX/SPX to IPv4, and we can do the same when it comes to IPv6.
    http://www.darkreading.com/threat-intelligence/ipv6-to-complicate-threat-intelligence-l/240160628

  5. Microsoft recently released an excellent technical case study entitled "Security Patch Management Evolution for Datacenter Servers at Microsoft". In this case study they demonstrate how they were able to dramatically improve sever security at Microsoft datacenters implementing a combination of new technologies along with policy and process changes. The end result was a net positive improvement in overall server security.
    http://technet.microsoft.com/en-us/library/dn425171.aspx

  6. I'll admit that I'm not a fan of Oracle's Java software. My loathing of Java dates back to my earliest days in IT when I was a desktop support technician responsible for about 500 desktops in my business unit. Having to support Java, and multiple different versions of it, and having to deal with application incompatibilities and challenges with authenticating proxies drove me crazy. Many years later when I became involved with information security I gained new ways to detest Java as it was riddled with security bugs, difficult to keep up to date, and almost impossible to effectively manage at enterprise scale. It appears that things haven't gotten much better. Recently Java was updated to warn users about the security risks associated with running Java content. They failed miserably in this effort, as it appears that spoofing information in this new dialog box is trivial.
    http://krebsonsecurity.com/2013/09/researchers-oracles-java-security-fails/

  7. Phillip Hallam-Baker of the Comodo Group recently published a draft RFC outlining security considerations in a post-PRISM world. In light of the recent revelations of NSA surveillance of Internet communications, this paper talks about some of the ways in which we can maintain privacy when communicating over the public Internet.
    http://www.ietf.org/id/draft-hallambaker-prismproof-req-00.txt

WindowSecurity.com Articles of Interest

  1. Least Privilege Eases Whitelisting Requirements
  2. Complacency: The 8th Deadly Sin of IT Security – Part 1
  3. The Journey to ISO 27001 – Part 2
  4. Big Data: The Security Perspective – Part 2
  5. Microsoft Windows Server Update Services (WSUS) Voted WindowSecurity.com Reader's Choice Award Winner for Patch Management

Windows Security Tip of the Month

Service accounts often present a serious challenge to security administrators. Typically these accounts have passwords that never change, are shared among services running on multiple hosts, and sometimes (although never a good idea!) they require domain administrative privileges. To address these concerns, Windows Server 2008 R2 introduced the Managed Service Account (MSA). MSA featured automatic password management and Service Principal Name (SPN) registration for service accounts. Initially it looked like a solid way to address the real and persistent problem with service accounts. However, MSAs didn't work with popular services like Exchange and SQL. They could not be shared across multiple hosts, which was a common deployment scenario. MSAs could not be used to run scheduled tasks either, which was probably the most common use case for service accounts. Fortunately Microsoft has realized the shortcomings of MSAs, and beginning with Windows Server 2012 there is a new feature called Group Managed Service Accounts (gMSA). gMSAs address all of the shortcomings of MSAs. gMSAs can be leveraged by Exchange, SQL 2012, and IIS application pools. They can be shared across multiple hosts, and can now run scheduled tasks. Thank you Microsoft! All that's required to take advantage of gMSAs is at least one Windows Server 2012 domain controller, a Windows Server 2012 or Windows 8 computer with the AD PowerShell module installed, and a Windows Server 2012 or Windows 8 domain member to run or use the gMSA. For more information about Windows Server 2012 Group Managed Service Accounts, click here.