• 05/14/2014
    8:00 AM
    Natalie Timms
  • Natalie Timms
  • Commentary
  • Connect Directly
  • Rating: 
    0 votes
    Vote up!
    Vote down!

Building An Information Security Policy, Part 5: Managing Identities

The final installment of this series looks at how to assign identifiers to users and devices for a secure network.

In my previous blog post in this multi-part series on constructing  an information security policy, I reviewed identifiers such as IP addresses and VLAN IDs and their role as security policy match criteria for identifying traffic flows subject to features such as firewalling and IPS services. In the  final post in this series, I'll review  secure assignment of identifiers to end entities, such as users and devices. I'll also discuss manipulation techniques that impact security policy, and new role-based identifiers that may be used in lieu of more traditional network topology-based constructs.

The allocation of addresses and other identifiers to users and devices must be handled with security in mind. When managing VLANs, consider techniques such as VTP with pruning, implement PVST (Per-VLAN STP), and secure it with features such as Root Guard, BPDU Guard, and disabling dynamic trunking.  Private VLANs (PVLANs) also are useful for segmenting traffic and protecting important resources.

Address assignment methods should be controlled and secured; this is simpler for static assignment to resources that do not change frequently. Dynamic assignment is required for users and devices that may be transient in nature. Allowing access dynamically is best handled by DHCP, which where possible, should follow authentication and authorization of the end entity via RADIUS Whenever a DHCP server is used, secure the service using techniques such as DHCP snooping, and Dynamic ARP Inspection. It's also important to track assigned addresses by associating MACs to IPs to prevent spoofing.

Using authentication methods such as 802.1X or MAB and tying them to device profiling and security posture assessments introduces the concept of authorized network access based not only on identity, but also device capabilities and compliance status.

Manipulation techniques and security
Allocated addresses may need to be translated to allow access to private services from a public network, or to hide the real address of a private resource. Get familiar with uni-directional vs. bi-directional access when configuring NAT and PAT methods. If a translated address is used to initiate traffic flows (to allow connectivity to a web server, for example), a bi-directional method like a static public to private mapping is required. This also can be combined with application port mapping, which forces connectivity via a non-standard port, hiding the real port from potential exploits.

If address translation is not an option, but connectivity across a WAN or the Internet to remote sites is required, consider tunneling methods such as IPv6-in-IPv4 or IPv4-in-IPv4 tunnels, which may also be protected with IPsec.

Once users and devices access the network, a solid understanding of routing protocols and packet-forwarding techniques adds to overall security. Static routes help  redirect traffic for security reasons. Policy-based routing can also redirect or discard traffic as well as mark certain flows for priority handling. Be familiar with best practices for dynamic routing protocols as well as any security mechanisms associated with them --  for example, authentication of routing updates via MD5 and TTL maximum hop limits for Open Shortest Path First (OSPF) and Border Gateway Protocol (BGP).

Role-based identifiers
Role-based identifiers that add context to a security policy beyond topology-dependant constructs such as IP address are another technology to consider when building your information security policy. Some vendors offer identity-based firewalling where a username-IP address mapping is used to enforce policy.

Other methods exist whereby a Security Group Tag (SGT) is assigned to groupings of end entities according to roles and functions. Dynamic assignment is via a RADIUS-driven authorization profile and static assignment is used to apply SGTs to devices, subnets and other groupings that do not tend to change their location. Although IP addresses are still assigned and used for routing and forwarding, the SGT value is used as the security policy match criteria.

The use of SGTs for policy provides a method for uniform enforcement regardless of the location of the end entities or the underlying network topology.

Careful consideration of the issues I've discussed in this blog series will pay off when planning an information security policy. Ultimately, a detailed and comprehensive security policy will ensure deployment and configuration is less prone to error and successfully -- and securely -- reflects business objectives.


policy maintenance

Thanks for this series Natalie. What kind of maintenance program should organizations plan on to keep their information security policy updated?

Re: policy maintenance

Entities should plan regular health checks to monitor the effectiveness of their policies in terms of:

1. Blocking threats successfully

2. Limiting false positives

3. Tuning rules, signatures, thresholds etc

4. Feedback from users - e.g. how many helpdesk issues have been reported related to security that may have been incorrectly applied

5. Overall performance of network devices and systems - are they handling load, do they need to be tuned

Some of this information can be relayed to management to illustrate the impact of the security policy to ensure its continued support.

This is on top of regular viewing of syslogs, netflows and anomaly reports. If required review risk ratings and make policy adjustments. This will be handled by the security and network teams at a technical level.

Regular review will help identify both policy issues and the need for equipment changes. If new services or networks are planned, this should always be done with a view to the current state of the network and its security policy. This information is useful at budget time.

Rule of thumb: threats and new requirements never sleep neither should your policy.


Re: policy maintenance

Natalie, thanks for the additional details -- these will realy help readers make their policies living and breathing documents. I love that you inlcuded feedback from users as one of the the things you should be including on a regular basis. I've never seen that as something to think about in the case of security, but it makes a lot of sense!

Re: policy maintenance

Nice article and good info in the comments. When you mention feedback from users do you just mean looking at help tickets? I'm not sure what kind of feedback you would get from users on a security policy. I guess if you had a select few to ask... you may give them ideas on how to breach it, or try to.

Re: policy maintenance

Paul, feedback from users would include reviewing issues that were logged with a help desk or other online tracking system. There could also be periodic discussions with group or department leads that cover work efficiency and network/application usability. So while you would not be specifically asking a user about the actual policy, you may glean useful information that could lead to performance tuning, or better policy application. You could also discover the need to add new features like SSO or increase productivity by allow some BYOD access. The human element also comes into play - at least giving people an opportunity to give feedback allows them to feel part of the process and it can also be educational for both the responder and the respondee.

Re: policy maintenance

Thanks for the answer Natalie. I can see that is very important to do. Getting the people involved is important as well. It would be selected people who were involved but nonetheless, get them involved.

Security vs. Usability / Productivity

It has been my experience that IT systems can be locked down to a point where they are not only off-limits to those who do not have access, information about their availability is also kept secret. 

A common scenario that I have seen in the corporate world is when a new hire comes in as a replacement to someone who left.  IT policy states that one cannot simply give the new-hire access to everything that the previous hire had because a number of exceptions or special use approvals may have been given to the previous person which do not apply to the new person. 

For a number of reasons, IT may not be willing to disclose to the dept supervisor what access the previous person had, say for example if IT is interested in phasing out a given system through attrition or perhaps IT does not want word to spread that a given resource or exception can be made such as increased storage quoatas or content filter exceptions.

The new employee finds himself/herself unable to perform the duties of the previous person in the same way and is also not aware of what specific access he/she needs to request.  In the name of security, IT stays hush hush on the matter.

Re: Security vs. Usability / Productivity

Yet another good reason to be aware of the various roles and their associated access within an organization. Security policies should be customized for specific business, security and accessibility requirements. This in turn suggests the way to monitor and evaulate the success or failure of that policy must also be customized. Some organizations may be more open to user inputs and comments than others so the trick is to use other methods of gathering heuristics and feedback in the more "closed" environments.

Re: Security vs. Usability / Productivity

Abe, your point is important. I agree with natalie's response and think that in some cases companies have good reasons for being more closed-mouthed about their security. However, in other companies, it's simply a matter of bad communication. Employees should always know what access they should have and be able to ask for, and as you note, that's often not the case. A lot of the time, they don't even know who to ask! So having a feednback loop to establish these lapses can help to fix those problems.

Re: policy maintenance

This is really solid guidance Natalie, thanks. I especially like the rule of thumb. Security policies should be seen as living documents that need ongoing maintenance.

Useful tips

Information security should be open access to all. I read your previous part 4 and I like most this part-5.

It all Starts with Information Security 101 - Policies, Proce...

As an information security specialist for many years, I unfortunately see the same recurring theme with businesses time and time again, and that's the failure to implement comprehensive policies and proceudures, processes, and other fundamental initiatives.  With so many free and cost-effective solutions available online, there's really no excuses as to why businesses don't take the necessary steps for ensuring the safety and security of one's entire network infrastructure. What's also frustrating is not seeing comprehensive security awareness training and other basic, fundamental programs, like annual risk assessments, that should be in place for further helping protect organizational assets.  There are literally hundreds of sites offering free employee training material. It's time companies got serious about security and not just profits because data breaches are continuing to grow at such an alarming rate. Think about it, what business do you even have if a significant data breach occurs? Kiss your profits goodbye and say hello to the onslaught of lawsuits sure to arrive. 

Re: It all Starts with Information Security 101 - Policies, P...

Thanks for weighing in here @gosmartyjones. You'd think in the wake of so many data breaches that companies would put more of a priority on security and at least implement the fundamentals to protect their business.