Pierluigi Paganini
April 10, 2015
A major obstacle that management must face in today’s world is the task of securing their organization’s assets. While physical security is a huge component in ensuring that the residual risk level existing within the environment remains at an acceptable level, our reliance on the Internet as a primary resource introduces a new set of risks and threats that are evolving by the second. There are various different pieces that must be taken into consideration and cooperate to build an efficient information security foundation for an organization. These pieces are known as security controls, and there are multiple different categories of these controls. From one standpoint, we can classify these security controls as physical, administrative and technical controls.
Physical security controls are those that secure, as the classification states, physical assets. These are implemented to protect the physical components of an organization; such as constructing high fences around an office building, data center, or other location to prevent intruders from easily gaining access to the building that houses critical data. Ensuring that the area around the building is well-lit, that physical authentication, authentication, and accountability controls are implemented and enforced; you wouldn’t want just anybody walking into your data center that houses your organization’s critical infrastructure devices (i.e. servers that store confidential data, etc.) and doing whatever they please, right? This category encompasses the security controls that prevent this from happening, such as mantraps and security guards.
Technical security controls can be physical devices or logical devices that play a huge role in today’s world. These controls are those that us in the information security and technology fields are most familiar with, and focus on. These include simple devices such as routers that provide NAT (Network Address Translation) services to allow users to access the Internet, making each user’s Internet traffic appear to be sourced from the same static IP address, or firewalls that dictate which IP addresses or what traffic can enter and exit your network.
As time passes, our technical security controls are those that are advancing in sophistication at an exponential rate, at a much faster pace than controls defined within the other categories. We have gone from simple firewalls with limited filtering capabilities to next-generation firewalls that perform the functions of multiple devices all-in-one. We have the capability to check end-user devices and infrastructure devices alike for specific configuration settings, patches, and other characteristics with such precise granularity that allow us to restrict access to an internal network, or place them in an entirely different network (i.e. a quarantine network managed by a NAC (Network Access Control) device) until the device meets the exact conditions that we set.
Technical controls are extremely important, and can be further broken down into three subcategories: Detective, Preventive, and Corrective (or perhaps Reactive is a better term). I will not go into the nuts and bolts of technical controls, but their importance must be stated. A huge roadblock preventing organizations from acquiring and implementing technical controls, especially in the case of smaller organizations, are the financial implications associated with such activities. These devices can be quite expensive, and the costs associated with not only purchasing the actual devices, but actually hiring qualified individuals to configure and manage these utilities can quickly drain a budget.
Administrative security controls are those that are not physical devices nor can they necessarily be considered logical devices. These are the fine-print that many employees seem to skim through, sign off on, and thereby embrace whatever the document says without having a true understanding of what is being presented to them. We encounter administrative controls on a daily basis, perhaps without even realizing it. When you download software, you often are required to read a large blob of text and click a checkbox that states that you have read and understand the terms outlined in the presented text. Administrative controls encompass policies, procedures, guidelines and documentation of this nature. While often overlooked, the administrative side of the fence severely impacts the state of an organization. The foundation—the framework—of every organization must be the development of policies and procedures. These documents govern every aspect of an organization, and lay out what is expected of employees of all levels, what the organization does, how it performs these actions, what to do in certain situations, and guidelines can aid the lesser-experienced and more well-versed employees of all levels with step-by-step instructions detailing how to successfully and correctly carry out a desired action. I will not begin to list and go through the endless number of different administrative controls (or documents) that are in existence, but to focus on only a subset, that when not enforced or implemented properly can have an extremely detrimental impact on an organization.
There are many different components that comprise the infrastructure of an organization that must be implemented and maintained in a manner that provides the highest level of protection, the best defense, as well as an efficient procedure to follow in the event that an incident occurs. The desired level of protection as well as the goals and methods of achieving this level of protection are often declared within an overarching security policy, but various policies are required to perform in a supplementary fashion to best achieve this goal. Common policies and procedures that will be found in most established organizations include an Acceptable Use Policy (AUP), a 3rd Party Device Policy, and On-boarding and Off-boarding Procedures to name a few. This article was written to highlight a major area that most organizations are lacking, based on my experiences, where the deficiencies in these areas resulted primarily in the loss and/or destruction of data.
While it is true that often times the compromise of devices and data through the threats I am about to mention are not quite as prevalent as the media makes them seem, the exponential growth and sophistication of malware delivery in particular through these exploitation methods is not to be taken lightly. I am referring to the increasing number of exploit kits found in-the-wild today. An exploit kit, as could be inferred by its name, is literally a kit of different scripts that are designed to exploit vulnerable software. While they are primarily built with the goal of exploiting vulnerabilities that are known to exist in various versions of common software, of which both you as well as I likely have installed on our devices (albeit, a patched version, I hope).
Over the past few years, the number of unique as well as the sheer quantity of unique instances of exploit kits in-the-wild has grown rapidly. While a phishing e-mail with a URL leading to an exploit kit landing page (the page of an exploit kit that actually performs the vulnerability checks and serves the exploits to vulnerable hosts) is still common, newer tactics such as the issue with malvertising campaigns (malicious advertisement campaigns in which advertisements displayed on even legitimate websites may redirect users to landing pages, and exploit the users without direct interaction with the malware author [such as via a URL sent within an e-mail]) has become a pain for security analysts globally. Now this is not to say that the risk of infection via an exploit kit could be mitigated entirely by making sure that software is up-to-date; this year alone started off with the release of a number of zero-day exploits (exploits previously unknown to the developer and/or security community as a whole) in Adobe’s Flash Player application were leveraged by many exploit kits, potentially affecting even users with even the most up-to-date version of Flash Player at that time.
The point is that the potential for compromise and overall risk level of an end-user device in particular can be greatly decreased through the enforcement of an efficient patch management policy.
A proper patch management policy should first categorize assets in terms of severity level, or the impact that such device(s) becoming compromised could have on the organization as a whole. This allows for the prioritization of patch deployment, ensuring that the most critical devices are focused on first. The prioritization allows for the allocation and development of set dates and times, whether daily or at regular intervals, that each device (or group of devices) will be patched. Once these steps are complete, the “backbone” of the patch management policy can now be referenced when going into the specifics of the policy. Where the patches will be retrieved from, whether on an OS level or individual device level basis, must be defined.
It is important that patches are not first rolled out to the production network; a development-type network environment should be in existence where these patches are first tested to ensure that the production network is not negatively impacted by the roll-out of the new patches. Once patches are obtained and tested, the scheduling of as well as the actual roll-out of these patches must be coordinated.
Important: Change management and patch management go hand-in-hand. Change management begins during the planning process and takes place throughout the full lifecycle of each managed device. Roles and responsibilities must be defined, each stage and process of patch management must be tracked, and additional procedures must be put into place detailing the actions to be taken in the event that something goes wrong.
What defines a successful patch deployment? What defines a failed roll-out? Criteria surrounding what constitutes as a success (as well as the opposite) must be clearly defined. Additionally, time management plays a huge part; management must aim to have all patches rolled out and deployed in the least amount of time that will not negatively impact the efficiency of other phases (such as the testing phase), to minimize the inevitable window of non-compliance that assets awaiting patches will face.
Whenever I am doing work within a client’s environment, whether it be product-related in terms of deployment or management or performing audit work (such as a vulnerability assessment or a gap analysis), I often encounter one of the applications that are a part of what I like to call “the big players” in terms of their use by an attacker as an infection vector.
A common example is the deployment of an outdated version of Internet Explorer (whether IE 9 or versions as early or earlier than IE 7) as a standard operating procedure within an organization, with the outdated software being a part of the baseline image rolled out to all [new] devices. While we all have our own personal browser preferences, Internet Explorer is known to contain a large quantity of vulnerabilities, especially in such outdated versions. When I was performing some research on exploit kits, one in particular whose control panel’s screenshots were publicly available, revealed that the majority of successful exploitations performed by that particular affiliate’s exploit kit deployment (up to 85%) were through the exploitation of vulnerable versions of Internet Explorer.
So why do we still see companies rolling out vulnerable versions of software to their end-users as part of a standardized procedure? Often, this is because of compatibility issues between certain software utilized within the environment. Many applications rely on outdated versions of browsers to function properly, and while I am tempted to refer to these applications as legacy applications, this is not always the case. While some software may be easier to use, contain specific functionality that is desired, or whatever the case, if the deployment of said software will introduce various commonly exploited risks to the organization, the software should simply not be used. Alternatives exist for virtually every type of software, and each have their own individual sets of pros and cons that must be weighed.
Another administrative component of an organization that perhaps has the greatest effect on the organization’s security posture, is the organization’s users. After all, no security tool can be efficiently used if the operator has no knowledge of how to correctly, efficiently do so. The same goes for users that have no direct technical responsibilities, i.e. a sales department. If your end-users are not aware of the threats that exist, especially those that they are more than likely to encounter, they will fail to successfully identify and prevent themselves from becoming victims. An in-depth discussion on “securing layer 8” of an organization is reserved for another article, but it’s important to mention that policies must be implemented and enforced that mandate users to undergo security awareness training at regular intervals, regardless of whether such training is delivered in person or online. It is unfortunate, but not quite shocking, that an enforced security awareness policy is essentially nonexistent within an otherwise established organization.
Many organizations simply present employees with an Acceptable Use Policy (AUP) or set of guidelines during their initial on-boarding, that are often either skimmed through by the new hire or actually read but forgotten almost immediately. The threat landscape that we face is constantly evolving, but in addition to new threats and methods of compromise, those that were “at large” and are thought to be rare and “outdated” are also often recycled. Old phishing e-mails designed to scam the recipient, Microsoft Word documents with embedded-macros, and other attacks that we consider deprecated are emerging once again and still to this day manage to fool the unsuspecting user. It is important that new hires are not the only ones that are mandated to undergo some form of security awareness training as part of their on-boarding process, but that all end-users within the organization are mandated to partake in such training sessions at regular intervals, as well as in response to a successful compromise or new threat being discovered.
While I may have gotten carried away in the first few sections of the article, it is important to understand the following:
As security professionals, it is our job to protect our users; we are often the voice that gets heard when upper-management is looking to design a security architecture, or implement a security control. We should not be exposing our users to an insecure environment; to the Internet, which is now a relatively dangerous place that comes with inherent risks. Our job is to do whatever we possibly can with the resources we have on-hand to best ensure our users’ security; not throw them into the fire with a disadvantage that gives the attackers the upper hand.
About the Author Michael Fratello
Edited by Pierluigi Paganini
(Security Affairs – security, threat prevention)
