Archive for October, 2009

What We’re Reading, Week of 10/26

Posted: October 30, 2009 in Highlights

Keep Your Laptop Off Our Inadequate Network
In this post, Jonathan Feldman asks why IT people resist end-users bringing their own equipment to the enterprise network. To be able to address issues like this, InformationWeek launched a research survey about end-user device practices in enterprise networks. We look forward to seeing the data and hearing what people had to say!

Enterprise Networking Planet…
Build an IPSEC VPN Without Losing Your Mind
In this article, Charlie Schluting offers some tips on how to build an IPsec VPN. Most people expect to have a difficult time configuring IPsec, but Charlie explains the concepts and makes it a less intimidating process for readers.

Should Your Enterprise Network Be An Internet Hot Spot?
Alexander Wolfe discusses whether enterprises should open up their networks, effectively turning them into Internet hot spots. With the emergence of both cloud computing and Windows 7, he says this could be a growing trend. Wolfe suggests Microsoft’s new operating system makes it unnecessary for users to launch VPN clients; instead, the discovery and authentication takes place automatically in the background anytime and anywhere a user connects to the Internet. Therefore, the average user will now perceive the Internet and his/her corporate network as pretty much one and the same thing. What do you think about the idea of the enterprise network as an Internet hot spot?

Continuing with our how to rethink remote access series, IT expert Travis Fisher has shared some thoughts on remote access policy with us. Travis is the Executive Vice President of Inacom Information Systems in Salisbury, MD, specializing in developing strong, secure reliable networks for Delmarva organizations.

I’d like to discuss something that isn’t necessarily policy centric, but needs to be addressed during implementation. One thing that isn’t well discussed at this point is who owns the computer during the remote connection and how is it used.

All too often, I see organizations that want remote access, but they do not understand the vulnerabilities that exist when you let an uncontrolled device VPN into your network. At this point, they are behind any access controls and security devices that you have in place. If it’s a shared PC in the family, you open yourself up to all the threats encountered when people consume all of the content on sites that are inappropriate for the workplace.

If you are going to let remote users connect via VPN, you should have a Network Access Control (NAC) solution in place. This will make sure that the device conforms to your security policies.

The general idea is to mitigate the risks associated with granting network access to different classes of users or even to devices that are not directly under the company’s control. It’s going to be up to the network administrator to deploy and configure a NAC solution based upon the needs and resources of their organization.

Common policies that NAC enforces include the device having a current antivirus definition and scan, that the device is validated to be a part of the network and granting appropriate resources for the user. In the event that the remote connection request is not in compliance, the device and user are quarantined until problems can be resolved (i.e., the device can have a new AV definition sent to it, missing patches, etc). The overall goal is to meet any security or regulatory needs in a way that minimizes risk given the amount of management resources available to the administrator.

The next IT expert in our how to rethink remote access series is Javed Ikbal. Javed is the Chief Security Officer at zSquad, an Information Security consulting company in the Boston area. His specialty is building or re-engineering information security programs. Javed has taken some time to share his thoughts on remote access policy.

– Define who may get remote access and the documentation/authorization for getting that privilege
– Document and define the add/change/delete process
– Define if the VPN can be installed on personally owned HW or not
– Prohibit split tunneling
– Enforce endpoint security (patches, AV, local firewall)
– Activity they can do while connected to the VPN

What We’re Reading, Week of 10/19

Posted: October 22, 2009 in Highlights

Around the blogosphere…
With the release of Windows 7 today, there has been quite a bit of discussion about the new version and its features. We have captured some articles and posts that have shared some insight into what Windows 7 will bring.
Why Cisco Isn’t Doing What is Right for the Client
In this post, Ed Horley suggests that Cisco is not doing what is right for their customers by only offering a 32-bit VPN client. Many people have upgraded to Windows 7 and 64-bit and he is frustrated that there is no Cisco supported 64-bit IPSec client for Windows Vista or 7.

To 64-bit or Not 64-Bit?
Steve Kleynhans discusses that with the launch of Windows 7, corporate customers need to start thinking about 64-bit. If it is not the right time to make the move, they should start preparing for the inevitable 64-bit shift. He suggests that at the very least everyone should include one 64-bit environment in their testing matrix. Steve has been using 64-bit and although he hit a showstopper with his corporate VPN, he resolved the issue and has been successfully running a beta VPN client for several months. If you haven’t already, do you think you will make the transition to 64-bit?

Cnet News
Windows 7 Debuts in New York
In this Live Blog, Ina Fred is updating us with what is happening in New York as CEO Steve Ballmer introduces Microsoft’s newest operating system at a special event. Balmer and Brad Brooks, Windows’ VP of Marketing are showing the crowd Window’s 7 coolest features.

The Windows Blog
What People Are Saying About Windows 7
Blogger, Brandon LeBlanc shares with us a social media “hub” for Windows 7 on  This hub is designed to highlight what consumers are saying about Windows 7, by pulling content from all over the web (via tweets, blog posts, etc.) and bringing it all to one spot.  It’s a great (and convenient) tool to see different opinions on W7.

Moving along with our series on how to rethink remote access, IT expert Mark David shares some thoughts on remote access policy. Mark is the Chief Security Officer and Systems Manager at Carta Worldwide, which deploys MasterCard branded prepaid chip cards.

The answer to this, as is often the case with IT solutions, is a multi-layered policy approach. For example, instead of having just a VPN account and a password, the user or the user’s manager must explicitly request access, the resources the user must have access too, and a mandatory maximum age of access past which the account must be renewed or terminated. A certificate to be issued from an issuing service that specializes in this form of distribution or from an in-house site that enforces this maximum age. ACLs and/or RADIUS type policy rules that specify each user’s authentication AND authorization along with a host of other mechanisms and measures to stop and mitigate threats.

Many administrators and contractors look to certificates to achieve a level of protection of the endpoints by forcing the end users to have a trusted certificate installed before their machine is let inside the network. However, the policy for their deployment can easily be self-defeating by using things like auto-enrollment (Active Directory distribution of certificates automatically to clients) and single sign-on services (most commonly associated with MS Active Directory) so that an attacker who simply gains access to the user’s laptop while it’s logged in to the user’s account can connect remotely with no barrier whatsoever.

When designing an IT solution, it’s important to keep in mind that to the end users, it’s a business solution before it’s a technology solution. This gives rise to the phenomena of security becoming stronger towards the middle of a connection, furthest away from end users and weaker towards the end points. However, the connection is the least exposed to compromise in the middle and most exposed at the endpoints.

Sure, in an ideal scenario, the goal would be to attain and then maintain trust in a given connection from the very first moment it is provisioned all the way until it is removed from the system. Therefore, the foundation should always be the access policy and the measures enforced by the policy to ensure only a trusted human being is given a connection into the network. Trust in the individual requesting the connection can be attained by methods such as performing an interview and/or requiring managerial authorization. Once trusted, the connection should be fit into an authentication scheme that requires dual-control, ie, a certificate and a password to make it more difficult for thieves to gain access after steeling a user’s laptop or some other form of illicit access to a terminal. And yes, NAC can fit in here as well to make sure the hardware and OS maintains a minimal degree of trust, and is free of malicious code. An authorization infrastructure (RADIUS, TACACS+, Active Directory or other) should also be in place and enforcing a policy to allow the user access to only required resources. At the application level, the policy should also enforce specific user rights to the maximum degree of granularity available to the specific application being accessed; a business user, for example, may need to download sales reports, but may have no need to access customer’s private information. While the connection is active, the connecting server(s) should be gathering user event logs which should be monitored at least daily; the purpose behind this is actually prevention—your users should know the corporate IT goons are combing over everything they do when connected, so this will keep them honest when tempted to share their laptop with someone who shouldn’t have access to it. Bad password lockouts don’t need to be very aggressive, but they do need to exist in order to thwart brute-force or dictionary attacks.

Besides the access control policy, there is, of course, network design considerations. An ideal scenario would include a honeypot and strict separation of production/sensitive servers from infrastructure/client systems. One cheap way to neatly accommodate that is do what I did for my company which deals with processing credit card transaction—place a multi-role firewall/router (Cisco, Checkpoint, Sonicwall, MS-ISA, etc) as the not only the edge security, but also the router for the entire network; that way, traffic flow can be explicitly controlled to and from certain hosts and networks in a seamless, centralized fashion without weakening security or incurring large costs. For example, if one user needs to remotely access systems in the business network but also has a need to download a file from the production network, it would just be a matter of creating an ACL to allow that specific user to access a specific port or protocol on a specific server.

In short, an ideal remote access system is a comprehensive, cradle to grave trust model based on a detailed access policy enforced by the relevant technology.