Information Security Today Home

New Books

Building an Effective Information Security Policy Architecture, Sandy Bacik, ISBN 9781420059052, $79.95
Mobile Device Security: A Comprehensive Guide to Securing Your Information in a Moving World
Security Strategy: From Requirements to Reality
Adaptive Security Management Architecture
Defense against the Black Arts: How Hackers Do What They Do and How to Protect against It

Whitelisting

Sandy Bacik

Access control consists of permitting or denying the use of a particular resource. Within networking environments, particularly at the network perimeter, enterprises have used blacklisting. Blacklisting consists of banning a list of resources from access. As the unauthorized and invalid access attempts increased, the blacklist continued to grow. This method allowed everything unless explicitly denied; i.e., default allow. Enterprises are now doing the reverse, only allowing authorized access; i.e., whitelisting, the "known good." Whitelisting turns blacklisting upside down, categorizing everything as bad except for a small group. Whitelisting is listing entities that are granted a set of privileges (access, services, validity, etc.) within an environment. A whitelist is solely used to define what is allowed to be executed, whereas anything that is not included on the whitelist cannot be executed.

Due to compliance, audit, and regulatory requirements, the enterprise resources and assets function should be documenting assets and resources. Resources can be groups, services, applications, computers, servers, routers, websites, etc. In small enterprise environments, a general purpose server is used for all manner of things (surfing the Web, reading e-mail, running enterprise applications, evaluating new software, etc.) and it is very difficult to keep whitelisting restrictions up to date for access. On the other hand, when a server has very few functions (like one used for just reading e-mail), using whitelisting can greatly improve security. Unfortunately, most enterprise systems fall somewhere near the middle between these two extremes. There are many types of whitelists an enterprise can utilize to assist in implementing whitelisting over blacklisting:

  • E-mail: An e-mail whitelist is a list of contacts that the user deems are acceptable to receive e-mail from and should not be sent to the trash folder, similar to spam filters.
    • Internet Service Providers (ISP): ISPs receive requests from legitimate companies to add them to the ISP whitelist of companies.
    • Noncommercial whitelists: Noncommercial whitelists are operated by various non-profit organizations, ISPs, and other entities interested in blocking spam.
    • Commercial whitelists: Commercial whitelists are a system by which an internet service provider allows someone to bypass spam filters when sending e-mail messages to its subscribers in return for a prepaid fee, either an annual fee or a per-message fee.
  • Local Area Network (LAN) whitelists: Many network admins set up Media Access Control (MAC) address whitelists, a MAC address filter, or subnets to control who is on their networks. This can be used when encryption is not a practical solution or in tandem with encryption. However, it's sometimes ineffective because a MAC address can be faked. Many firewalls can be configured to only allow data traffic from or to certain (of IP addresses.
  • Program whitelists: Enterprises should keep a list of valid software within the network. If an organization keeps a whitelist of software, only titles on the list will be accepted for use. The benefits of whitelisting in this instance are that the school administration can ensure itself that students will not be able to download or use programs that have not been deemed appropriate for use.
  • Application whitelists: Enterprises should do regular application inventories for license agreements. One approach to combat viruses and malware is to whitelist software which is considered safe to run, blocking all others.

    Let's compare using blacklists and whitelists for access control (see Table 2.1). There are more advantages and fewer disadvantages in using whitelists. Yet, there are two potential glaring issues with whitelisting. First, most organizations are apprehensive about going the whitelist route because the IT department does not want to increase the resources needed to manage the impact of keeping track of valid resources and impacting users.

    On the other hand, many organizations see explicitly denying things via a blacklist is not the most effective or productive way to manage and protect the environment. So it boils down to: What to do and why? The best approach depends on the solution to prevent execution of applications, services, and code. For example, if the implemented solution contains a very basic enforcement method that uses the "yes" or "no" to determine executability, then the enterprise might want to look elsewhere.

    Trying to use a whitelist with this logic could turn into a management nightmare while also dramatically impacting end-user productivity. Another example would be a solution using the methodology by defining rules. This methodology is flexible enough to effectively balance enforcement, management, and productivity. This is definitely not the endgame in endpoint protection. It does have a built-in target solution and can be easily maintained.

    In looking at today's enterprise, there are many requirements, standards, and policies that require access control to be implemented and reviewed on a regular basis for governance, audit and compliance. Implementing whitelisting will assist in making the audit and compliance reviews simpler to complete. Enterprises should have a list of valid applications, network equipment, customers, partners, sites/locations, employees, roles/groups, contractors, consultants, services, and ports. If an enterprise has these documented, they have a start on implementing a whitelisting solution for access control. See Table 2.2 for a sample listing of how whitelisting can be implemented for access control using some of the list above. Using the information in Table 2.1 and the examples in Table 2.2, an enterprise can better manage access control of resources and limit the risk to those resources.

    In conclusion, documenting all network resources and being able to use whitelisting will give the enterprise more control over those resources and lessen the risk to the enterprise. The upfront work for implementing whitelisting will require a larger effort. Once completed, the whitelisting will enable the enterprise to specifically know what resources are available and who has access to what resources. Overall, implementing whitelisting will reduce the risk of findings during a compliance audit.


    Related Reading

    Tomorrow's AV Marks the Good, the Bad, and the Long Tail/a>

    Attackers Exploit Trusted Entities/a>

    Convenience over Security: Creating Effective Mobile Security Policies/a>


    About the Author

    Sandy Bacik, CISSP-ISSMP, CISM, CGEIT, CHS-III, author and former CSO, has over 14 years of direct development, implementation, and management information security experience in the areas of audit management, disaster recovery and business continuity, incident investigation, physical security, privacy, regulatory compliance, standard operating policies and procedures, and data center operations and management. Ms. Bacik has managed, architected, and implemented comprehensive information assurance programs and managed internal, external, and contracted and outsourced information technology audits to ensure various regulatory compliance for state and local government entities and Fortune 200 companies. She has developed methodologies for risk assessments, information technology audits, vulnerability assessments, security policy and practice writing, incident response, and disaster recovery.

    From Information Security Management Handbook, Sixth Edition, Volume 5 edited by Harold F. Tipton and Micki Krause. New York: Auerbach Publications, 2011.

 
Subscribe to Information Security Today





Powered by VerticalResponse

Share This Article


© Copyright 2011 Auerbach Publications