Wednesday, April 10, 2013

Avoiding Security Monoculture


Ever so often we hear proclamations that certain security technologies, like antivirus, are failing so badly that they should be regarded as bygone defenses of simpler times.  These types of arguments arise with great regularity-- anyone remember the supposed demise of IDS?   While it's true that organizations are still spending a large percentage of their security budget on the "FAI" triad (Firewalls, Antivirus, IDS), there is no question as to whether these foundational defenses should be deployed (imagine a day without antivirus? no thank you!).

The bigger issue lurking behind our own reaction to the latest dismal AV catch-rate statistics or painful breach analysis is one that we aren't talking enough about. This is an issue that I call security monoculture.

The term monoculture found its origin in the agriculture industry. To drive greater yields, farmers began producing genetically similar species of crops.  The benefits of this approach included standardized production cycles, fertilization methods, and pest control techniques which could be scaled at less expense. The net impact of these innovations are extremely impressive (if you've ever driven across any of the state in the great plains, the results of this approach are quite hard to miss.); however, all choices have consequences on both sides of the ledger. In the way that every plant in a genetically similar monoculture has common defenses against threats, similarly, all members of the monoculture share common weaknesses. For this reason, diseases or pests who successfully establish themselves in these environments are capable of causing extreme damage.

You might ask what agriculture has to do with information security.  The truth is that there are trends in information security that invariably push us toward our own security monocultures. More specifically, there are a large number of organizations that have adopted security architectures whose defenses, processes, and methods are so similar that their risks are magnified substantially.

As a quick case in point, let's take our much beloved defense-in-depth strategy.  Defense-in-depth (DID for short) is in the heart and soul of every information security practitioner right up there with the CIA triad and Shon Harris books.   The concept behind defense-in-depth is extremely logical: to defend the things we care about, we build our defenses in a manner where the failure of one control/defense can be compensated by the operation of another.  It is quite easy and correct to visualize defense-in-depth architectures as a series of concentric circles: valuables inside, controls/defenses in-between, and evil outside the gates.  A full discussion of contemporary challenges for the DID model is a topic unto itself.  A key issue with defense-in-depth is not whether it is logical, rather, it is whether our approach to DID incorporates enough defensive diversity.

When we take a look at many organizations, we unfortunately often find the same security solutions mixed in with the same security deficits. This lack of defensive diversity is a god-send to an adversary who wishes us harm.  From the perspective of a hostile actor intent on exfiltrating data, the fact that our defensive controls are so similar means that she needs to modify very few of her methods to successfully evade detection and accomplish her mission.

Avoiding security monoculture requires a few things from us that start with our mindset and end in our practices:
  • Willingness To Lead -  As security professionals we have to be accountable for our decisions and our performance.  With security, however, there can be a great pressure to be in lockstep with our peers.  If we are defending like everyone else and get hit, then it can honestly feel reassuring to  be able to state: "Everyone else is doing it this way."  Don't fall into this trap. It is one thing to selectively adopt good practices, but we must realize that all environments present unique challenges.  Be decisive and address these challenges based on your research, your experience, your best judgement and take accountability for your decisions.
  • Compliance ≠ Security -  If we are only concerned with making sure that all the checkboxes are filled, then we've embraced an approach that leads very quickly to security monoculture. Compliance should be treated as risk to be managed and not an end-goal. Any static defensive position becomes an almost immediate advantage to an adversary. Don't just reach compliance requirements and stop-- we have to keep going and develop our defenses in a manner that makes the most sense for our organizations.
  • Do The Basics Extremely Well - Often with security architecture we can build great walls around some really shoddy buildings.  While it is great fun to explore the latest exploit or new technology, we have to focus our efforts first and foremost on basic foundational practices like patch management, IAM, and change management review.  By formalizing and consistently executing these practices, we gain a great deal of differentiation from a large number of other organizations.
  • Active Defenses - This term seems to be somewhat en-vogue though it is often misunderstood.  Active defense isn't equivalent to "hacking back". A significant idea behind active defense is the implementation of non-passive controls which offer denial and deception capabilities.  The utility of active defense approach can be immense, and more organizations need to begin to develop defensive stratagems that include these measures. 
The challenges of security monoculture are significant, but organizations who understand this reality can, ironically, turn this situation to their advantage.   Defensive strategies which cultivate and exploit adversaries' own empirical assumptions can be extremely powerful.

In upcoming blog post, we'll examine ways that organizations can begin to leverage active defense strategies in their own environments.

Thursday, February 14, 2013

Announcing RŌNIN: A Linux DFIR and PenTest Distribution

I am pleased to announce the release of a new DefendLink project entitled RŌNIN.
"From one thing, know ten thousand..." -Miyamoto Mushashi

RŌNIN is a free linux security distribution (based on Lubuntu) that provides a platform both for training and conducting professional data forensics, penetration testing, and incident response engagements.

The primary objective of RŌNIN is to offer a fast/lightweight  linux desktop that includes a curation of security tools and resources that are useful for security professionals, instructors, and students alike.



RŌNIN has three main design goals that support this objective

1. Enhance Continual Learning - RŌNIN brings a wide array of documentation, video lessons, and other online materials together in one distribution.  By coupling the best tools together with easy access to reference materials and training resources, this project promotes development of concepts, tools, and techniques from a common platform.

2. Process Driven Design- Professional security engagements are built around a well defined set of goals, limitations, and deliverables.  RŌNIN  reflects this reality by placing tools into process areas where they might reasonably be used. For DFIR work, the structure is built around a basic Collection, Analysis, and Reporting model, and for security evaluation the layout is built around the  Penetration Testing Execution Standard.

3. Complete Work Platform - While RŌNIN comes loaded with security tools, it also provides popular linux desktop applications to extend a viable primary work platform for information security professionals.


To learn more about the RŌNIN project visit our web-site and/or download the latest release.



  

Thursday, February 7, 2013

Simple Answers to Security Complexity

One of the old adages in information security is that "complexity is the enemy of security".  The reasoning behind this is simple. Complex systems are much harder to map-out (large attack surfaces), are often very difficult to manage effectively, and the long-term behavior of a complex system is more difficult to predict reliably (vulnerabilities + fault conditions).

This adage is less of an academic or philosophical statement as it is an observation borne out by more than a few (usually quite painful) professional experiences concerning the impacts of complexity.  Given these experiences, one might assume that we've all learned our lesson and issued a declaration of "never again".

Except, of course, we can't really say this.  Complexity is unavoidable amid organizational pressure to   integrate, deliver, and leverage IT systems on ever shorter time horizons.  However, IT specialists aren't the only ones feeling the brunt of this. Contractual, legal, and regulatory complexity is also growing to an all time high. So much for simplicity, right?

Well, the truth is you can't manage complexity with even more complexity.  Now more than ever, managing Information Security challenges require a solid grasp of the answers to some deviously simple questions.   The answers to these questions are fundamental as they form a map to what really matters most. Three very fundamental simple questions that must be answered include:
  1. What are the mission and goals of your organization? 
  2. What does "security" mean in context to these objectives?
  3. How can you consistently generate and demonstrate value in support of these goals?

The key element with each of these questions is understanding how the mission of  your information security program fits into the "big picture" of your organization.   There is a reason, however, why these are deviously simple questions.  Finding the answers is a bit like assembling a puzzle.  Your senior executives will have some crucial pieces, but you will discover that other key insights come from line managers and end-users. Knowledge of varied business operation requirements within your organization is also essential to identifying which pragmatic security-tradeoffs both protect and enhance the capability of your organization to hit its targets.

Obviously, you build and refine this picture over time and continually adjust your security program in commensuration not only to new threats/obstacles but also to the evolution of new goals and opportunities.  Unfortunately though, many often put the cart before the horse.  They attempt to deal with complex issues (the "how') before they've attempted to gain any insight into basics (the "why").  Failures to address (and readdress) these simple questions inevitably lead to very costly and visible course corrections.

Dealing with these simple questions takes prioritization, patience, ability to listen, and often someone to help bring a valuable external perspective.  As always, the devil may be in the details, but someone has to be responsible for determining which set of details matter most.

Wednesday, January 30, 2013

Security QuickGuide: UPnP Vulnerabilities

Yesterday, the US Computer Emergency Response Team released an advisory concerning vulnerabilities in the Universal Plug and Play (UPnP) protocol suite.  Because of the widespread use of UPnP, this issue does have some potential for broad impact.

What is UPnP?
The UPnP is actually a collection of protocols that allow for devices to easily advertise services within a networked environment as well as establish adhoc service paths for file sharing, gaming, printing, and other common services.  The UPnP architecture was principally designed for residential environments to allow for consumers to more easily interconnect their devices without need of a central directory.  It's important to keep in mind that UPnP isn't a terrible secure protocol framework.  It  employs no authentication between devices or service sets and therefore is not appropriate for use in Enterprise environments.

What is The Issue?
Rapid7 recently discovered and published a paper and advisory on buffer-overflow vulnerabilities in UPnP for devices that employ older unpatched revisions of UPnP SDK/libraries within their devices.  The vulnerability is manifest in the incorrect handling of malformed frames used by the SSDP discovery service protocol. Unfortunately, it really takes only one malformed UDP packet to exploit this weaknesses (anyone remember SQL Slammer?).  These buffer overflows may be used for remote code execution attacks against a family or grouping of susceptible devices.

How To Address This
First,  you shouldn't assume the sky is falling.  However it would be wise to perform a directed risk assessment  to determine if you may have devices with UPnP turned on and whether or not they may be vulnerable.   Even in Enterprise computing environments, you can expect that printers and other devices may have default configurations that enable UPnP.  More seriously, if you deploy any SOHO type router/firewalls then you should definitely check these devices as well.

Here are some tips that can help formulate a plan-of-attack for assessing this issue:

#1. Make Sure that You Are Filtering Unsolicited UPnP 
Surprisingly, Rapid7's research into this issue found that 2.2% of all public IPv4 addresses responded to UPnP discovery requests (approx 81 million devices).  Don't let this be you!  Check your firewall rules and your configurations on WAN side interfaces for any UPnP settings.

UPnP use the following Ports for service discovery
Unicast UPnP Discovery Traffic =  tcp/udp 1900
Multicast UPnP Discovery Traffic = 239.255.255.250:1900

(Also, Rapid7 offers a free  online UPnP scan  that will check to see if your public IP address responds to UPnP service discovery requests.)

#2. Scan For Vulnerable UPnP Enabled Devices
 For Windows users, there is a free Scanning Tool that will probe for devices that respond to service discovery requests and determine if these devices are using an unpatched revision of UPnP.

Also it is possible to scan for vulnerable devices in Metasploit using the steps listed below.


If the scans uncover known devices that may be vulnerable then you will see response strings like the ones below:
MiniUPnPd ProcessSSDPRequest() Out of Bounds Memory Access Denial of Service
MiniUPnPd ExecuteSoapAction memcpy() Remote Code Execution
Portable SDK for UPnP Devices unique_service_name() Remote Code Execution


#3. Disable UPnP or Check For Updates
If you discover devices that are vulnerable and you don't need UPnP, then disable it within the device and then scan it again to validate that it is off.

If  your stuck with UPnP, then check with the vendor for updates on new patch releases.  A list of responding vendors can be found here:

Hope this is a helpful quick guide!

Sunday, January 27, 2013

HELLO WORLD!

Thanks for visiting the DefendLink blog!

Defendlink is an independent information security company that specializes in assisting organizations efficiently manage their information security risks. If you are visiting for the first time, please be sure to check out our site at www.defendlink.com.  

Also, we are very close to releasing some exciting news regarding a new free resource that will soon be made available through DefendLink.

So stay tuned!...