Wednesday, July 18, 2012

MORPHINATOR & cyber maneuver as a defensive tactic

In June I read an outstanding paper from MAJ Scott Applegate, US Army, entitled The Principle of Maneuver in Cyber Operations, written as part of his work at George Mason University.
Then yesterday, I spotted a headline indicating that US Army has awarded a contract to Raytheon to develop technology for Morphing Network Assets to Restrict Adversarial Reconnaissance, or MORPHINATOR.
Aside from what might be the greatest acronym of all time (take that, APT) MORPHINATOR represents a defensive tactic well worthy of consideration in the private sector as well. While the Raytheon article is basically just a press release, I strongly advocate your reading MAJ Applegate's paper at earliest convenience. I will restate the principles for you here in the understanding that these are, for me, the highlights of this excellent research, as you might consider them for private sector use, and are to be entirely attributed to MAJ Applegate.
First, understand that the United States Military describes the concept of maneuver as "the disposition of forces to conduct operations by securing positional advantages before and or during combat operations."
MAJ Applegate proposes that the principles of maneuver as defined above require a significant amount of rethinking when applied to the virtual realm that constitutes cyberspace. "The methods and processes employed to attack and defend information resources in cyberspace constitute maneuver as they are undertaken to give one actor a competitive advantage over another."
While cyber maneuver as described in this paper include elements of offensive and defensive tactics, I think it most reasonable to explore defensive tactics as the primary mission when applied to the private sector.
While I privately and cautiously advocate active defense (offensive reaction to an attack) I'm not aware of too many corporate entities who readily embrace direct or overt offensive tactics.
The paper indicates that: "Cyber maneuver leverages positioning in the cyberspace domain to disrupt, deny, degrade, destroy, or manipulate computing and information resources. It is used to apply force, deny operation of or gain access to key information stores or strategically valuable systems." While this reads as a more offense-oriented statement, carry forward disrupt, deny, degrade, and manipulate to a defensive mindset.
Applying parts of MAJ Applegate's characteristics of cyber maneuver to defensive tactics would include speed, operational reach, dynamic evolution, rapid concentration, non-serial and distributed. Consider these in the context of private sector networks while reviewing direct quotes from the paper as such.
  • Speed: "Actions in cyberspace can be virtually instantaneous, happening at machine speeds."
  • Operational Reach: "Reach in cyber operations tends to be limited by the scale of maneuver and the ability of an element to shield its actions from enemy observation, detection and reaction."
  • Dynamic evolution: "Recent years have seen rise to heavy use of web based applications, cloud computing, smart phones, and converging technologies. This ongoing evolution leads to constant changes in tactics, techniques and procedures used by both attackers and defenders in cyberspace."
  • Non-serial and distributed: "Maneuver in cyberspace allows attackers and defenders to simultaneously conduct actions across multiple systems at multiple levels of warfare. For defenders, this can mean hardening multiple systems simultaneously when new threats are discovered, killing multiple access points during attacks, collecting and correlating data from multiple sensors in parallel or other defensive actions."

Incorporating the above characteristics as part of defensive tactics for the private sector does not negate the need to fully understand and defend against the additional characteristics found in the research including access & control, stealth & limited attribution, and rapid concentration. Liken access & control here to a "forward base" concept allowing attackers "to move the point of attack forward." Stealth & limited attribution clarifies that while action in cyberspace is "observable" most actions are not observed in a meaningful way." Think of this, in all seriousness as "what you don't know will kill you." Rapid concentration represents the mass effect of botnets and DDoS attacks and the ease with which they're deployed in cyberspace. As defenders we must be entirely cognitive of these elements and ensure agility in our response to the threats they represent.

Now to close the loop (analogy intended, see the paper's reference to an OODA (Observe-Orient-Decide-Act) loop) as it pertains to defensive tactics. The Principle of Maneuver in Cyber Operations offers four Basic Forms of Defensive Cyber Maneuver, three of which directly apply to private sector network operations.
  1. Perimeter Defense & Defense in Depth: Well known, well discussed, but not always well-done. "While defense in depth is a more effective strategy than a line defense, both these defensive formations suffer from the fact that they are fixed targets with relatively static defenses which an enemy can spend time and resources probing for vulnerabilities with little or no threat of retaliation."
  2. Moving Target Defense: "This form of defensive maneuver uses technical mechanisms to constantly shift certain aspects of targeted systems to make it much more difficult for an attacker to be able to identify, target and successfully attack a target." This can be system level address space layout randomization (ASLR) or constantly moving virtual resources in cloud-based infrastructure.
  3. Deceptive Defense: "The use use of these types of (honeypots) systems can allow a defender to regain the initiative by stalling an attack, giving the defender time to gather information on the attack methodology and then adjusting other defensive systems to account for the attacker’s tactics, techniques and procedures."
Drawing from part of MAJ Applegate's conclusion, when considering the principles described herein, "while maneuver in cyberspace is uniquely different than its kinetic counterparts, its objective remains the same, to gain a position of advantage over a competitor and to leverage that position for decisive success. It is therefore important to continue to study and define the evolving principle of maneuver in cyberspace to ensure the success of operations in this new warfighting domain."
I contend this is not a war pending, but a war upon us.
 While The Principle of Maneuver in Cyber Operations discusses this declaration specific to military operations, we are well advised to consider this precision of message in the private sector. GEN Keith Alexander, U.S. Cyber Command chief and the director of the National Security Agency, was recently quoted as saying that the loss of intellectual property due to cyber attacks amounts to the “greatest transfer of wealth in human history.” GEN Alexander went on to say "What I’m concerned about is the transition from disruptive to destructive attacks and I think that’s coming. We have to be ready for that."
Private sector and military resources alike need to think in these terms and act decisively. Cyber maneuver tactics offer intriguing options to be certain.
Use MAJ Applegate's fine work as reference material to perpetuate this conversation, and may the MORPHINATOR be with you.

Monday, July 02, 2012

toolsmith: Collective Intelligence Framework

Linux for server, stable on Debian Lenny and Squeeze, and Ubuntu v10
Perl for client (stable), Python client currently unstable


As is often the case when plumbing the depths of my feed reader or the Dragon News Bytes mailing list I found toolsmith gold. Kyle Maxwell’s Introduction to the Collective IntelligenceFramework (CIF) lit up on my radar screen. CIF parses data from sources such as ZeuS and SpyEye Tracker, Malware Domains, Spamhaus, Shadowserver, Dragon Research Group, and others. The disparate data is then normalized into repository that allows chronological threat intelligence gathering.   Kyle’s article is an excellent starting point that you should definitely read, but I wanted to hear more from Wes Young, the CIF developer, who kindly filled me in with some background and a look forward. Wes is a Principal Security Engineer for REN-ISAC whose mission is to aid and promote cyber security operational protection and response within the higher education and research (R&E) communities. As such the tenor of his feedback makes all the more sense.
The CIF project has been an interesting experiment for us. When we first decided to transition the core components from incubation in a private trust-based community, to a more traditional open-source community model, it was merely to better support our existing community. We figured, if things were open-source, our community would have an easier time replicating our tools and processes to fit their own needs internally. If others outside the educational space benefited from that (private sector, government sector, etc), then that'd be the icing on the cake.
Years later, we discovered that ratio has nearly inverted itself. Now the CIF community has become lopsided, with the majority of users being from the international public and private spaces. Furthermore, the contribution in terms of testing, bug-fixes, documentation contributions and [more importantly] the word-of-mouth endorsements has driven CIF to become its own living organism. The demonstrated value it has created for threat analysts, who have traditionally had to beg-borrow-and-steal their own intelligence, has become immeasurable in relation to the minor investment of adoption.
As this project's momentum has given it a life all its own, future roadmaps will build off its current success. The ultimate goal of the CIF project is to create a uniform presence of your intelligence, somewhere you control. It'll read your blogs, your sandboxes, and yes, even your email (if you allow it), correlating and digging out threat information that's been traditionally locked in plain, wiki-fied or semi-formatted text. It has enabled organizations to defend their networks with up to the second intelligence from traditional data-sources as well as their peers. While traditional SEMs enable analysts to search their data, CIF enables your data to adapt your network, seamlessly and on the fly. It's your own personal Skynet. :)

Readers may enjoy Wes’ recent interview on the genesis of CIF, available as a FIRST 2012 podcast.
You may also wish to take a close look at Martin Holste’s integration of CIF with his Enterprise Log Search and Archive (ELSA) solution, a centralized syslog framework. Martin has utilized the Sphinx full-text search engine to create accelerated query functionality and a full web front end.

Installing CIF

The documentation found on the CIF wiki should be considered “must read” from top to bottom before proceeding. I won’t repeat what’s also been said (Kyle’s article has some installation pointers too), but I went through the process a couple of times to get it right so I’ll share my experience. There are a number of elements to consider if implementing CIF in a production capacity. While I installed a test instance on insignificant hardware running Debian Squeeze, if you have a 64-bit system with 8GB of RAM or more and a minimum of four cores with drive space to grow into, definitely use it for CIF. If you can also install a fresh OS, pay special attention to your disk layout while configuring partition mapping during the Large Volume Manager (LVM) setup. Also follow the postgres database configuration steps closely if working from a fresh install. You’ll be changing ident sameuser to trust in pg_hba.conf for socket connections. On weak little systems such as my test server, Kyle’s suggestion to update work_mem to 512MB and checkpoint_segments to 32 in postgresql.conf is a good one. The BIND setup is quite straightforward, but again per Kyle’s feedback, make sure your forwarder IP addresses in /etc/resolv.conf match those you configure in /etc/bind/named.conf.options.
From there the install steps on the wiki can be followed verbatim. During the Load Data phase of configuration you may run into an XML parsing issue. After executing time /opt/cif/bin/cif_crontool -f -d && /opt/cif/bin/cif_crontool -d -p daily && /opt/cif/bin/cif_crontool -d -p hourly you may receive an error. The cif_crontool script is similar to cron, as I hope you’ve sagely intuited for yourself, where it calls cif_feedparser to traverse and load CIF configuration files then instructs cif_feedparser based on the configs. The error, :170937: parser error : Sequence ']]>' not allowed in content, crops up when cif_crontool attempts to parse the cleanmx feed definition in /opt/cif/etc/misc.cfg. You can resolve this by simply commenting out that definition. Wes is reaching out to to get this fixed, right now there are no other options than to comment out the feed.
To install a client you need only follow the Client Setup steps, and in your ~/.cif file apply the apikey that you created during the server install as described in CIF Config. Don’t forget to configure .cif to generate feed as also described in this section.
A final installation note: if you don’t feel like spending the time to do your own build you have the option to utilize a preconfigured Amazon EC2 instance (limited disk space, not production-ready).

Using CIF

You should set the following up, per the Server Install, as a cron job but for manual reference if you wish to update your data at random intervals, run as sudo su - cif:
1)  PATH=/bin:/usr/local/bin:/opt/cif/bin
2)      Pull feed data:
a.  cif_crontool -p daily -T low
b.  cif_crontool -p hourly -T low
3)      Crunch the data: cif_analytic -d -t 16 -m 2500 (you can up –t and –m on beefier systems but it my grind your system down)
4)      Update the feeds: cif_feeds
You can run cif from the command line; cif –h will give you all the options, cif –q where query string is an IP, URL, domain, etc. will get you started. Pay special attention to the –p parameter as it helps you define output formats such as HTML or Snort.
I immediately installed the Firefox CIF toolbar, you’ll find details on the wiki under Client | Toolbars | Firefox as it make queries via the browser, leveraging the API a no-brainer. See WebAPI on the wiki under API. Screen shots included hereafter will be of CIF usage via this interface (easier than manually populating query URLs).
There a number of client examples available on the wiki, but I’m always one to throw real-world scenarios at the tool du jour. As ZeuS developers continue to “innovate” and produce modules such as the recently discovered two-factor authentication bypass, ZeuS continues in increased usage by cybercriminals. As may likely be the common scenario, an end user on the network you try desperately to protect has called you to say that they tried to update Firefox via a link “someone sent them” but it “didn’t look right” and that they were worried “something was wrong.” You run netstat –ano on their system and see a suspicious connection, specifically Ruh-roh, Rastro, that IP lives in the Ukraine. Go figure. What does Master Cifu say? Figure 1 fills us in.

FIGURE 1: CIF says “here be dragons”
I love, bad guy squatter genius. You need only web search ASN 49335 to learn that NCONNECT-AS Navitel Rusconnect Ltd is not a good neighborhood for your end user to be playing in. Better yet, cif –q AS49335 at the command line or drop AS49335 in the Firefox search box.
Figure 2 is a case in point, Navitel Rusconnect Ltd is definitely the wrong side of the tracks.

FIGURE 2: Can I catch a bus out of here?
 ZeuS configs and binaries, SpyEye, stolen credit card gateway, oh my.
This is a good time for a quick overview of taxonomy. Per the wiki, severity equates to seriousness, confidence denotes faith in the observation, and impact is a profile for badness (ZeuS, botnet, etc.).
Our above mentioned user does show in their browser history, let’s query it via CIF.
Figure 3 further validates suspicions.

FIGURE 3: Mazilla <> Mozilla
 You quickly discern that your end user downloaded bt.exe from You take a quick md5sum of the binary and drop the hash in the CIF search box. 756447e177fc3cc39912797b7ecb2f92 bears instant fruit as seen in Figure 4.

FIGURE 4: CIF hash search
 Yep, looks like your end user might have gotten himself some ZeuS action.
With a resource such as CIF at your fingertips you should be able to quickly envision value added when using a DNS sinkhole (hello or DNS-BH from where you serve up fake replies to any request for the likes of Bonus! Beefy server for CIF: $2499. CIF licensing: $0. Bad guy fail? Priceless.

In Conclusion

Check out the Idea List in the CIF Projects Lab; there is some excellent work to be done including a VMWare appliance, further Snort integration, a Virus Total analytic, and others. This project, like so many others we’ve discussed in toolsmith, grows and prospers with your feedback and contributions. Please consider participating by joining the CIF Google Group and jumping in. You’ll also want to check out the DFIR Journal’s CIF discussions, including integration with ArcSight, as well as EyeIS’s CIF incorporation with Splunk. These are the same folks who have brought us Security Onion 1.0 for Splunk, so I’m imaging all the possibilities for integration. Get busy with CIF, folks. It’s a work in progress but a damned good one at that.
Ping me via email if you have questions (russ at holisticinfosec dot org).
Cheers…until next month.


Wes Young, CIF developer, Principal Security Engineer, REN-ISAC

Moving blog to

toolsmith and HolisticInfoSec have moved. I've decided to consolidate all content on one platform, namely an R markdown blogdown sit...