Header
56 results were found... happy reading.

Tue, 10 Aug 2010

Information Security South Africa (ISSA) 2010
@

Last week we presented an invited talk at the ISSA conference on the topic of online privacy (embedded below, click through to SlideShare for the original PDF.)

The talk is an introductory overview of Privacy from a Security perspective and was prompted by discussions between security & privacy people along the line of "Isn't Privacy just directed Security? Privacy is to private info what PCI is to card info?" It was further prompted by discussion with Joe the Plumber along the lines of "Privacy is dead!"

The talk, is unfortunately best delivered as a talk, and not as standalone slides, so here's some commentary:

We start off the problem statement describing why privacy has grown in importance. The initial reactions were based on new technology allowing new types of information to be captured and disseminated. While the example given is from the 1980s, the reaction is a recurring one, as we've seen with each release of new tech (some examples: Cameras, Newspapers, Credit Cards, The Internet, Facebook). Reactions are worsened by the existence of actors with the funding & gall to collect and collate much information to further potentially disagreeable goals (usually Governments). However, the new threat is that there has been a fundamental shift in the way in which we live our lives, where information about us is no longer merely *recorded* online, but rather, our lives are *lived* on line. It is quite possible that for an average day, from waking up to going to sleep, a significant number of the actions you perform will not only be conducted (in part) online, but that it is possible for them to be conducted using the services of one service provider. My intention is not to beat up on Google, but rather use them as an example. They are a pertinent example, as every business book seems to use them as one. The, arguably, most successful corporation of our current age's primary business model is the collection & monetisation of private data. Thus, while Google is the example, there are and will be many followers.

The next section moves into providing a definition of privacy, and attempts to fly through some fairly dry aspects of philosophy, law & psychology. We've done some entry-level work on collating the conception of privacy across history and these fields, however, brighter minds, such as Daniel Solove and Kamil Reddy have done better jobs of this. In particular, Solove's paper "I've got nothing to hide", and other misconception of privacy is a good introductory read. The key derived point however, is that private data is data with an implied access control & authorised use. Which of the implied access controls & authorised uses are reasonable to enforce or can be legally enforced is a developing field.

As the talk is about "Online Privacy" the talk moves into a description of the various levels at which private data is collected, what mechanisms are used to attempt to collect that data, and what sort of data can be gleaned. It was an academic conference, so I threw in the word "taxonomy." Soon, it will be more frequently quoted than Maslow's Hierarchy, any day now.

At each level, a brief demonstration of non-obvious leaks and their implications was demonstrated. From simple techniques such as cross-site tracking using tracking pixels or cookies, to exploit of rich browser environments such as the simple CSS history hack, to less structured and less obvious leaks such as search data (as demonstrated by the AOL leak), moving to deanonymisation of an individual by correlating public data sets (using the awesome Maltego) and finally to unintended leaks provided by meta-data (through analysis of twitter & facebook friends groups).

Finally, a mere two slides are used to explain some of the implications and defenses. These are incomplete and are the current area of research I'm engaged in.

Sat, 7 Aug 2010

BlackHat Write-up: go-derper and mining memcaches
@

[Update: Disclosure and other points discussed in a little more detail here.]

Why memcached?

At BlackHat USA last year we spoke about attacking cloud systems, while the thinking was broadly applicable, we focused on specific providers (overview). This year, we continued in the same vein except we focused on a particular piece of software used in numerous large-scale application including many cloud services. In the realm of "software that enables cloud services", there appears to be a handful of "go to" applications that are consistently re-used, and it's curious that a security practitioner's perspective has not as yet been applied to them (disclaimer: I'm not aware of parallel work).

We choose to look at memcached, a "Free & open source, high-performance, distributed memory object caching system" 1. It's not outwardly sexy from a security standpoint and it doesn't have a large and exposed codebase (total LOC is a smidge over 11k). However, what's of interest is the type of applications in which memcached is deployed. Memcached is most often used in web application to speed up page loads. Sites are almost2 always dynamic and either have many clients (i.e. require horizontal scaling) or process piles of data (look to reduce processing time), or oftentimes both. This implies that the sites that use memcached contain more interesting info than simple static sites, and are an indicator of a potentially interesting site. Prominent users of memcached include LiveJournal (memcached was originally written by Brad Fitzpatrick for LJ), Wikipedia, Flickr, YouTube and Twitter.

I won't go into how memcached works, suffice it to say that since data tends to be read more often than written in common use cases the idea is to pre-render and store the finalised content inside the in-memory cache. When future requests ask for the page or data, it doesn't need to be regenerated but can be simply regurgitated from the cache. Their Wiki contains more background.

go-derper

We released go-derper, a tool for playing with memcached instances. It supports three basic modes of operations:
  1. Fingerprinting memcacheds to determine interesting servers
  2. Extracting a (user-limited) copy of the cache
  3. Writing data into the cache
The tool has minor requirements: a recent Ruby and the memcache-client gem. What follows are basic use cases.

Fingerprinting

Let's assume you've scanned a hosting provider and found 239 potential targets using a basic .nse that hunts down open memcached instances3. You need to separate the wheat from the chaff and figure out which servers are potentially interesting; one way to do that is by extracting a bunch of metrics from each cache. Start small against one cache: insurrection:demo marco$ ruby go-derper.rb -f x.x.x.x [i] Scanning x.x.x.x x.x.x.x:11211 ============================== memcached 1.4.5 (1064) up 54:10:01:27, sys time Wed Aug 04 10:34:36 +0200 2010, utime=369388.17, stime=520925.98 Mem: Max 1024.00 MB, max item size = 1024.00 KB Network: curr conn 18, bytes read 44.69 TB, bytes written 695.93 GB Cache: get 514, set 93.41b, bytes stored 825.73 MB, curr item count 1.54m, total items 1.54m, total slabs 3 Stats capabilities: (stat) slabs settings items (set) (get)

44 terabytes read from the cache in 54 days with 1.5 million items stored? This cache is used quite frequently. There's an anomaly here in that the cache reports only 514 reads with 93 billion writes; however it's still worth exploring if only for the size.

We can run the same fingerprint scan against multiple hosts using

ruby go-derper.rb -f host1,host2,host3,...,hostn

or, if the hosts are in a file (one per line):

ruby go-derper.rb -F file_with_target_hosts

Output is either human-readable multiline (the default), or CSV. The latter helps for quickly rearranging and sorting the output to determine potential targets, and is enabled with the "-c" switch:

ruby go-derper.rb -c csv -f host1,host2,host3,...,hostn

Lastly, the monitor mode (-m) will loop forever while retrieving certain statistics and keep track of differences between iterations, in order to determine whether the cache appears to be in active use.

Mining

Once you've identified a potentially interesting target, it's time to mine that cache. The basic leach switch is "-l":

insurrection:demo marco$ ruby go-derper.rb -l -s x.x.x.x [w] No output directory specified, defaulting to ./output [w] No prefix supplied, using "run1"

This will extract data from the cache in the form of a key and its value, and save the value in a file under the "./output" directory by default (if this directory doesn't exist then the tool will exit so make sure it's present.) This means a separate file is created for every retrieved value. Output directories and file prefixes are adjustable with "-o" and "-r" respectively, however it's usually safe to leave these alone.

By default, go-derper fetches 10 keys per slab (see the memcached docs for a discussion on slabs; basically similar-sized entries are grouped together.) This default is intentionally low; on an actual assessment this could run into six figures. Use the "-K" switch to adjust:

ruby go-derper.rb -l -K 100 -s x.x.x.x

As mentioned, retrieved data is stored in the "./ouput" directory (or elsewhere if "-o" is used). Within this directory, each new run of the tool produces a set of files prefixed with "runN" in order to keep multiple runs separate. The files produced are:

  • runN-index, an index file containing metadata about each entry retrieved
  • runN-<md5>, a file containing the bytestream from a retrieved value
The mapping between key and file in which the value is stored occurs in the index file, which is useful in that potentially malicious data (keynames) aren't used when interacting with your local filesystem APIs.

At this point, there will (hopefully) be a large number of files in your output directory, which may contain useful info. Start grepping.

What we found with a bit of field experience was that mining large caches can take some time, and repeating grep gets quite boring. The tool permits you to supply your own set of regular expressions which will be applied to each retrieved value; matches are printed to the screen and this provides a scroll-by view of bits of data that may pique your interest (things like URLs, email addresses, session IDs, strings starting with "user", "pass" or "auth", cookies, IP addresses etc). The "-R" switch enables this feature and takes a file containing regexes as its sole argument:

ruby go-derper.rb -l -K 100 -R regexs.txt -s x.x.x.x

Over-writing

In this blog entry I don't cover the kinds of data we discovered (it'll be subject to a separate entry), however it may come to pass that you discover an interesting cache entry that you'd like to overwrite. Recall entries were stored in "./output" by default, with a prefix of "runN". If the interesting entry was stored in "output/run1-e94aae85bd3469d929727bee5009dddd", edit the file in whatever manner you see fit and save it to your local disk. Then, tell go-derper to write the entry back into the cache with:

ruby go-derper.rb -w output/run1-e94aae85bd3469d929727bee5009dddd

This syntax is simple since go-derper will figure out the target server and key from the run's index file.

And so?

Go-derper permits basic manipulations of a memcached instance. We haven't covered finding open instances or the kinds of data one may come across; these will be the subject of followup posts. Below are the slides from the talk, click through to SlideShare for the downloadable PDF.
1 http://www.memcached.org

2 We're hedging here, but we've not come across a static memcached site.

3 If so, you may be as surprised as we were in finding this many open instances.

Tue, 6 Apr 2010

BroadView V4 Attributes
@

Following on from Evert's posting about the new BroadView v4, I'd like to showcase a specific aspect of BV that we've found useful, namely Attributes. These are small pieces of data collected and maintained for each host scanned by BV including somewhat mundane bits of info like IP address and OS but, they also include some really tasty morsels about remote hosts that are scanned. Attributes are collected on a per-scan-per-host basis, and are populated by each test that runs during the scan. Since attribute population is dependent on the selected tests, the set of Attributes available to you would vary according to you configuration.

Consider the trivial attribute Network.TCP.HTTP.Banner; this doesn't require credentials to acquire and is stored by a test that detects webservers. On the other hand, the test that stores Users.Microsoft.Windows.Group.SystemOperators.Members would require domain credentials in order to pull the needed info. This is common inside of organisations, where BV is primarily intended.

To help me explain the power of Attributes a little easier, here are a few scenarios:

Your IT manager wants to know which Windows machines are missing the new MS10-018 patch. Instead of trawling through all the latest scans looking for hosts that are affected , you simply:

  1. Login to BroadView
  2. Click Attributes
  3. Select Patches.Microsoft.Windows.Missing
  4. Click MS10-018
  5. Download CSV
  6. Done
Perhaps you have rolled-out a new WSUS system and need to find all the Windows hosts still configured with the old WSUS server name. Again:
  1. Login to BroadView
  2. Attributes
  3. Config.Microsoft.Windows.WSUS.Server
  4. Click the name of the old WSUS server
  5. Download CSV
  6. Done
Or you are trying to find all the hosts with a specific piece of software installed (e.g. uTorrent). Click Attributes >> Software.Installed.Microsoft.Windows >> uTorrent >> Download CSV.

One of the IT techies gives you a call:

Bob: Hey Steve Steve: Ahoy Bob: Do you know which FTP servers on the network allow Anonymous access? Steve: Ofcourse I do Login to BroadView >> Attributes >> Network.TCP.FTP.IsAnonymousAccessAllowed >> True >> Download CSV Steve: You got mail Bob: Awesome, thanks

As you can see the power and extensibility of BroadView Attributes is (according to opinions from the office) Simply Astonishing(tm). We are currently working with our Assessment team to include Attributes that would allow them to very quickly pull a list of all "low hanging fruit" vulnerabilities when performing an internal Pen Test.

Currently we collect just over 50 attributes, but are adding new ones as we either think of or clients request more. The full list is:
Patches.Microsoft.Windows.Missing
Services.Microsoft.Windows.Running Users.Microsoft.Windows.Local.LastLoggedIn Users.Microsoft.Windows.Local.NeverLoggedIn Users.Microsoft.Windows.Local.PasswordNeverExpires Users.Microsoft.Windows.Group.AccountOperators.Members Users.Microsoft.Windows.Group.BackupOperators.Members Users.Microsoft.Windows.Group.PrintOperators.Members Users.Microsoft.Windows.Group.Replicators.Members Users.Microsoft.Windows.Group.SystemOperators.Members Users.Microsoft.Windows.Network.NeverChangedPasswords Users.Microsoft.Windows.Network.NeverLoggedOn Users.Microsoft.Windows.Network.PasswordNeverExpires Users.Microsoft.Windows.ActiveDirectory.Group.Members Users.Microsoft.Windows.ActiveDirectory.AccountsOld.Members Users.Microsoft.Windows.ActiveDirectory.AccountsStale.Members Users.Microsoft.Windows.ActiveDirectory.AccountsBadLogins.Members Users.Microsoft.Windows.ActiveDirectory.AccountsOldPassword.Members Users.Microsoft.Windows.ActiveDirectory.AccountsPasswordNeverSet.Members Users.Microsoft.Windows.ActiveDirectory.AccountsDisabled.Members Users.Microsoft.Windows.ActiveDirectory.AccountsLocked.Members Config.Microsoft.Windows.Domain.IsCorrect Config.Microsoft.Windows.Domain.Value Config.Microsoft.Windows.WSUS.Server Config.Microsoft.Windows.WSUS.Server.IsConfigured Config.Microsoft.Windows.WSUS.Server.Value Config.Microsoft.Windows.MachineName Debug.Network.IsHostAccessible
Debug.Microsoft.Windows.Registry.Access.Full Debug.Microsoft.Windows.Registry.Access.Read Debug.Microsoft.Windows.Registry.Access.Fail Debug.Microsoft.Windows.Privileges.Admin.Full Debug.Microsoft.Windows.Privileges.Admin.Fail ServicePacks.Microsoft.Windows.Win2k3.Value ServicePacks.Microsoft.Windows.Win2k3.IsInstalled ServicePacks.Microsoft.Windows.NT4.Value ServicePacks.Microsoft.Windows.NT4.IsInstalled ServicePacks.Microsoft.Windows.Win2k.Value ServicePacks.Microsoft.Windows.Win2k.IsInstalled ServicePacks.Microsoft.Windows.XP.Value ServicePacks.Microsoft.Windows.XP.IsInstalled Software.Microsoft.Office.Value Software.Microsoft.Office.IsInstalled Software.Microsoft.SMSAgent.IsInstalled Software.Microsoft.SMSAgent.IsRunning Software.Microsoft.SMSAgent.IsInstalled Software.Microsoft.SMSAgent.McAfee.EPOAgent.IsInstalled Software.AntiVirus.Linux Processes.Microsoft.Windows Network.TCP Network.TCP.FTP.IsAnonymousAccessAllowed Network.TCP.SMTP.IsRelayAllowed Network.TCP.HTTP.Banner Network.TCP.HTTP.Directories Network.TCP.Banner Network.TCP.SMB.Direcotories Network.UDP.DNS.ReverseDNS Network.UDP.LDAP.BaseObject

Tue, 30 Mar 2010

BroadView - coming of age
@

Ever since Ron Gula's RiskyBusiness talk #142 about their Nessus philosophy, I decided to come out of the closet and share with our readers the work we do in the vulnerability management field. [Ed: If you don't listen to Risky Business then, as we say in South Africa, eish.] Ron explained that with Nessus they aim to give users a tool that can be used for monitoring and auditing - not enforcing. The "sed quis custodiet ipsos custodes" mantra comes to mind. For 9 years now we have been building two vulnerability management solutions named HackRack (for hosted, external scanning) and BroadView (for internal scanning) and it was especially HackRack that has claimed the limelight. The runt of the litter has always been BroadView, but alas (luckily?), no more.

We decided a while ago to invest our new ideas and technology in BroadView, and when that matured and stabilized, use the new BroadView as a base for new HackRack and HackRack PCI services.

And that process is nicely on track.

I mean, just look at this interface. The Blizzards page will allow BV users to get up to date stats about their environment but also allow them to quickly grasp the actual state of affairs on their network. Blizzards are visual sql queries that display averaged or calculated results of vulnerability scans as well as collected attributes. In the example below, one can quickly appreciate the impact of adding a batch of new machines to a scan, and the resulting impact on the New Issue count blizzard.

We don't see BV as just another vulnerability scanner. Its a data collector of note. It does not just scan,it also collects. From every networked device that is probed, attributes are collected that range from regular basic info such as IP addresses and operating system values, to machines without SMS agents and WebDAV directories on HTTP services.

In the weeks and months to come we will share with you the trial and tribulations to eventually bring to light BroadView v4, Final Release. We will share with you our frustration and jubilations in successfully executing intensity scans on virtualised hardware, how to mine for installed software on OS X and appreciating the amazing reduction in bandwidth utilisation by switching from SOAP to Thrift.

Well, I am off to go watch one our guys participate in a televised panel discussion - and at the same time figuring out if there are any advantages in being able to interface BroadView with our Saeco coffee machine ...

Wed, 17 Feb 2010

SensePost Ten Years Old
@

After ten fascinating years, during which many people have contributed in so many ways to the place that is SensePost, by strange coincidence it falls on me to pen the words that mark our first decade in existence. To quote Robert Hunter: "What a long strange trip it's been". SensePost was officially founded on February 14, 2000. Of everyone who was involved at that time, I'm the only one still working here, which earns me the dubious honor of 'oldest employee'. Do I get a gold watch? I meant to think much more over the last few weeks and months about how we should celebrate this day, or what I would write in a letter like this, but in the end (business being business) I'm writing this in a rush on a Sunday evening, with another three big things to complete before I allow myself to go to bed. Then again much of our success (in so far as we've been a success) happened in hurry on a Sunday night, so let's not write this little piece off too soon, shall we?

The vision for SensePost developed between myself and Roelof Temmingh late in 1999. To be fair, Roelof was by far the more skilled and experienced at that time, and the notion of a commercial venture rooted in computer hacking as a service was born primarily with him. But I like to think I played a small part in shaping and molding the ideas that formed during the early part of that summer. Certainly I believe it was my epiphany that as long as we waited for others to make the calls, we would never never really be in charge of our own destiny, that finally convinced us to leave our jobs and set out on this new venture. It was the height of the 'dotcom' boom, we knew more about everything than anyone, and we thought we'd be rich before two years were out. Of course it wasn't that simple, but its been a crazy happy journey nevertheless and I don't regret a minute of it.

It wasn't all about money of course. There was also a dream. We saw a small group of people, technical, hard working, passionate about computers and security, and with poor fashion sense. We had wild ideas about a grunge-style internet cafe with drinks named after shell commands, big screens and 70's pop. I also recall some discussions about a scooter with a fax machine mounted on it, but we won't go there. Basically, we had no idea what we were doing. Yup. Roelof and I had passion, idealism, energy, a whole lot of arrogance, and a little bit of skill, but not much more. We were 24 years old, had about US$ 6,000 between us, and probably barely enough collective business acumen to open a cheque account.

Help came from a very unexpected place. As it turned out the managing director of the company we were leaving, an ueber-suite, the boss of our boss, public enemy number one, prime-evil himself, had resigned the company just weeks before we did. His name is Luc de Graeve and instead of calling down the gods of corporate South Africa to punish us for our insolence, he kindly and gently offered us advice and support, which we eventually, suspiciously, accepted. And so was formed a relationship that would culminate with Luc becoming a major shareholder and our managing director for eight years until after we eventually sold to Secure Data in 2008.

In the sidelines at that time, but a secret member of our troupe right from the start, was Chris Erasmus. Chris has joined a team Roelof was starting at our previous company and we promised to invite him in the moment SensePost was on its feet. And so Chris joined us as a shareholder only a few short months after we started. Although Chris was the first of the founders to leave, he played a formative role in establishing our culture, values and identify. His sincere manner and unique stye left an indelible impression on each of us and on the business itself that can still be felt today.

And then there was Jaco. Jaco van Graan had also worked with Roelof, Luc and me, but had left before the rest of us to take a security job at a major ISP. On the side, he and two friends had started an accounting and audit practice called TJC. They planned to specialize in helping small businesses like ours and approached us with a very attractive proposal. Before too long Jaco would join us as 'financial director' and BS 7799 specialist. We wondered at the time whether it wasn't too soon to require a full time financial manager, but the indisputable balance and control we've had in all our financial and commercial matters since that day testify that it was the right call.

Next join our team was Haroon Meer. We met him online while he worked at Durban university and invited him to come visit us at the 'office' we ran out of Roelof's master bedroom. He soon went on to join the directors and eventually become our technical director and in many ways the heart and soul of our business. After I finish writing this post, I have to write some words for his farewell. His contract with Secure Data has expired and he's moving on to his next big adventure. I sincerely wish him well, but already miss him dearly.

The contract I'm referring to with Secure Data is part of the purchase agreement with them. Under that agreement three of the shareholders - myself, Haroon and Jaco - were obliged to stay for a fixed term after the purchase. That period has not yet ended, but Secure Data has allowed for him to break a little early. In this, and many other things, Secure Data has been a good partner to us. The decision to sell the business back in 2008 was a not an easy one and we entered into the deal and subsequent contract period with more than a little trepidation. But Dean and Johan have understood us well and have graciously allowed us to continue being who we are. Thus, I say with confidence, that nothing has changed in our culture or values since joining Secure Data. I suspect this is unusual in such cases, and I'm extremely grateful for it. Indeed, Dean has proven to be wise and insightful leader.

So our tenth birthday also marks the end of our journey with Haroon. Of the original people, only myself and Jaco now remain. I feel I've said goodbye to too many people over the past decade. I hate it. But I've also come to learn that the business is bigger than any individual one of us. Each time somebody leaves I dread it, and each time we somehow survive. Over the years the business has grown from strength to strength and today we boast much more skill, energy and talent than Roelof, Haroon, Chris, Luc, Jaco or I ever had.

Time doesn't allow me to tell the whole SensePost story in detail and I guess there's really not all that much to tell. But there are some players I just have to mention: My deepest love and respect to Roelof - my friend and mentor - and Luc - long our leader and the biggest set of footsteps anyone ever had to follow. @haroonmeer - I've already said how much I'll miss you. Chris - I hope to see you again soon. Kim, Gareth, Lizelle, Christoff, Herman, Jacof, Nithen, George, BradleyW, Craig, Lohan, Frank, James, Glenn - thank you all sharing a part of your journeys with us. And to our customers: I can't mention you by name, but some of you have supported us from the very beginning, and all of you have been gracious, patient, loyal and extremely supportive. Thank you! Without you we would lack any meaning. And I must mention … Black Hat. Ping and Jeff gave us a chance when nobody had to, and opened up the door that would eventually allow us to become a truly global company with customers on all five continents. Thank you Ping and Jeff. My hope is only that we can give people the kind of leg-up that Black Hat gave us.

So how have we done over the last ten years? The other day Haroon - ever our conscience - mentioned Sun CEO Jon Schwartz's memo at the time of the acquisition by Oracle. Haroon was saying how he kept record of the memo to remind himself of the kind of company he wants to work for, so I thought it might offer a good benchmark against which we can judge ourselves…

Schwartz: "Sun's people have always stood apart as the brightest, most passionate, and most inspiring… I've always been surrounded by the best and brightest individuals I've ever come across…"

I certainly don't count myself amongst the best and the brightest, and SensePost is certainly no Sun, but I can say honestly and sincerely, in the words of Schwartz himself: It's "been an honor and privilege, for which I'm enormously thankful".

Schwartz: "[Our] Technology, alongside our employees and partners, have changed the world"

From the beginning, SensePost has had the courage to build and release technologies that make a difference to how we think and work, have made a difference to our industry and ultimately to our customers. And we're still doing it today. Sure, our's is a small galaxy, but I'm proud of the difference we've made in it.

Schwartz: "Amidst the toughest market and customer situations imaginable, I'm proud we've always acted with integrity, with a sense for what's right, and not simply what's expedient."

This is perhaps the part of our makeup of which I'm the most proud. SensePost has always been a values-driven organization and I believe I can say with all truth that we've never compromised on our values. We've been fair and honest in all our dealings with our customers, our staff, our suppliers and even our competitors. I'm proud to say that I can't think of one person in our industry, in South Africa or abroad, that I'd be ashamed to run into.

Much of what's happened over the last ten years has taken me by surprise, so its hard to comment intelligently on what the next ten years will hold. But what I do know is this: At its heart, I believe, SensePost is about learning. Learning and teaching. We believed at the time (arrogantly I suppose) that we knew more than anyone else. Not anyone else in the whole world I mean, but the more than the people and businesses we were dealing with at the time. And our heart… was to teach them.

This spirit of teaching is still at the heart of our business model, and must remain at our own hearts also. Teaching is how we add value to everyone we deal with - our staff, but most especially our customers. Its a generous spirit, for to teach is a fundamentally generous thing. Teaching is not about fame or money, its about sincerely caring for the other and wanting to empower and enable them. The fame and money, if you're lucky, will follow.

To be a good teacher, however, one must first be a student. Thus, as the rate of technological development catapults, and as the world around us becomes ever more complex, we need to learn. We need to hunger for knowledge, insight and understanding and seek it out at every cost. We need to work harder, think deeper, push ourselves at every opportunity. The moment we stop doing this. The moment we start to make assumptions and take things for granted… that will be the moment when we start to fail.

And to end, two more quotes from Schwartz:

"We're known as self-starters, capable of ethically managing through complexity and change, for delivering when called upon, and for inventing and building the future. With the world economy stabilizing, I'm very confident you'll land on your feet. You're a talented, tenacious group, and there's always opportunity for great people."

So, to Jaco's team in finance - thank you for keeping the wheels turning and for reminding us what it is to 'serve' others. To the analysts in our assessment team - thank you for the continuous quality and passion of your work. That's how we roll. To the VMS team and developers, you hold the keys to our future. Keep it up - your moment will soon come. To Shane and Bradley, sales and presales - you are our link to our customers and the rudder that steers our ship. To Dominic in consulting - thanks for joining us at last. To Junaid ... welcome on board. May your full potentials be realized with us. To others that have already left us - thank you for sharing with us - may you have success wherever your paths have taken you.

And finally:

"Thank you, again, for the privilege and honor of working together."

URL for Schwartz's memo to Sun: http://news.cnet.com/8301-1001_3-10440125-92.html

Blog
Video
Research
QotW
Categories
about:us (31)
blackhat (5)
blog (10)
broadview (2)
build-it (1)
cloud (12)
community (15)
conferences (60)
crypto (3)
fail (3)
foos (1)
fun (51)
goodbye (1)
hackrack (2)
Hope? (2)
howto (8)
imsojaded (2)
infosec-soapies (25)
infrastructure (3)
local (5)
mac (15)
management (7)
materials (3)
memcached (2)
mindless-politics (4)
mindmaps (1)
PCI (2)
post-it (1)
privacy (6)
product (2)
programming (5)
public (275)
qo[w|m|?] (5)
README (1)
real-world (14)
research (37)
reversing (4)
security-fyi (8)
security-news (6)
silly-yammerings (19)
tech-toys (3)
time-waster (6)
tin-foil-hat (6)
tools (46)
training (18)
travel (1)
tricks (1)
Uncategorized (3)
vendors (6)
videos (6)
vulnerability (7)
wasc (1)
webapps (6)
web_x.0 (2)
writing-advice (1)
zen-hacking (6)
Archives
August 2010 (4)
July 2010 (1)
June 2010 (4)
May 2010 (3)
April 2010 (3)
March 2010 (7)
Feburary 2010 (2)
January 2010 (3)
December 2009 (4)
November 2009 (4)
October 2009 (3)
September 2009 (5)
August 2009 (9)
July 2009 (1)
June 2009 (5)
May 2009 (4)
April 2009 (10)
March 2009 (13)
Feburary 2009 (12)
January 2009 (11)
December 2008 (9)
November 2008 (8)
October 2008 (5)
September 2008 (5)
August 2008 (6)
July 2008 (6)
June 2008 (6)
May 2008 (2)
April 2008 (3)
March 2008 (7)
Feburary 2008 (12)
January 2008 (9)
December 2007 (8)
November 2007 (4)
October 2007 (9)
September 2007 (14)
August 2007 (18)
July 2007 (13)
June 2007 (17)
May 2007 (2)
July 2006 (1)
April 2006 (1)
August 2005 (1)
June 2005 (1)
May 2005 (2)
Archives
Conditions of use Privacy statement
Top of Page Legal stuff