Information Security, Privacy and Regulatory Compliance - Soapbox

No Expectation of Privacy, for employeers or emplyees [Employers Monitor, Employees Push Back]

nospam@example.com (Keith Pachulski) — Thu, 12 Aug 2010 14:30:00 -0400

Employee and Employer expectation of privacy has always been a hot topic, of course with the constant changes in technology it can make the enforcement of privacy policies and controls nearly impossible for employers whether they be public or private sector. In a recent article written by Katharine H. Parker in the New York Law Journal, she also touch on this.

As employers literally struggle to protect against the "unauthorized" access, use and dissemination of information I pull out the ShoeWand and deem the greater portions of privacy implementations "not-secure".

Any one who has been reading my blog for awhile now knows I am a strong advocate of proper policy definition, implementation and enforcement. The struggle though is with how employees knowingly and without care will ignore the policies set for by the organizations they work for.

When you, as an employer, develop your policies focusing on both proper use of company resources as well as the CIA (confidentiality, integrity and availability) of sensitive or private information, the policy must be explicit in definition. There can be no room for interpretations or "void for vagueness" statements within the policy. Again, we are focusing on the expectation of privacy here.

Employees must only be permitted to access that information to which is required by their job function. They must do so only from company allocated devices. Access to said information from any non-company issued devices must not be permitted. Accesses must must tracked/audited on an ongoing basis by the security team within your organization.

Any violations must follow a documented procedure for internal reporting and punishment must be both swift and public. By public I mean when employees are discovered attempting to access, or have accessed, information they are not authorized or are accessing information from devices not under the control of the company, it must be made know to the rest of the organization that "we" are monitoring and will penalize through X defined method noted in X document. The enforcement/punishment must adversely impact the individual otherwise the punishment will be ignored.

It MUST also be known to all employees that the company is monitoring and recording all activities and it must be made clear there is no expectation of privacy.

Examples:
1) Employees are accessing external webmail to send internal information so they can "work on it at home".
2) Employees are utilizing company issued portable devices to engage in non-business related activities.
3) Employees bring their personal laptops into the company to perform personal activities while on company time

The network use policy must clearly state that X type of network traffic is permitted, it must also state that the company reserves the right to monitor and record all network traffic it in sole determination deems as inappropriate without the consent or knowledge of the employee.

It must be stated the personal devices are not permitted to be connected to the company network. The company reserves the right to monitor at all times any and all devices accessing the company network as well as record all network traffic from rogue devices without the consent or knowledge of the employees.

Company issued devices must not be permitted to be used as a personal device, the company must reserve the right to locally or remotely monitor all activities and traffic sourced/destined to the company owned device and that the employee may not at any time modify the configuration to disallow authorized internal security personnel access to the device and that such accesses are permitted without the knowledge or consent of the employee. Bearing in mind the potential implications of this type of design, a solid security plan must be properly developed and tested.

At no point should a company ever offer to pay for an employees personal device and expect to retain and degree of control or privacy or the configuration or the information being stored on the device. End of story there, if it is not a company issued device, it should not be used for accessing company information.

If specific employees, or groups of employees, for their job function do not need access to resources external the company; the solution is simple, do not give it to them. Monitor, record and any intentional attempts to circumvent the control must result in immediate disciplinary action by the company.

We are far too lenient in my opinion in this day and age with our employees. While we need to retain a happy and productive work-force, we do not need to allow employees to jeopardize the operations of the company because of unconcerned employees.

For the employers, if your policies are not well defined in that you do not allow X behavior or you do not enforce those policies equally in both monitoring and enforcement. When the day comes that you are called to the courtroom and it is show you selectively enforce the policies, I can assure you that you will lose.

So again:

Develop your policies and procedure
Training your employees at hire and at minimum yearly retrain them
Enforce the policies even upon all individuals within the company.

No one should be excluded, I don't care where they sit in the company.

// -> Rant Off

Social Engineering - It's not a new attack people

nospam@example.com (Keith Pachulski) — Sun, 08 Aug 2010 17:50:00 -0400

We had talked about this briefly on the podcast the other night, but I wanted to go into it further. it's one of those subjects that sticks with me...read into that how you want.

First off, to those of you who are reading this that don't know what social engineering is, here is the popular and generally accepted definition from wikipedia:

Social engineering is the act of manipulating people into performing actions or divulging confidential information, rather than by breaking in or using technical cracking techniques; essentially a fancier, more technical way of lying.[1] While similar to a confidence trick or simple fraud, the term typically applies to trickery or deception for the purpose of information gathering, fraud, or computer system access; in most cases the attacker never comes face-to-face with the victim.

The most basic form of Social Engineering can be viewed as the "breaking the ice" between a man and a woman. Man engages woman and through various discerned observations attempts to discern some information to further the encounter.

Note: If you`re new to the social engineering game, learn to start random conversations with men and women, regardless of how awkward the situation. Once you find you can enter into conversations with ease as well as exit from them with some useful information gleaned, you're on your way. By useful information I do not mean how the current weather is =)

Women are typically better at the social engineering game than men, though some will likely disagree with me on this. That's fine though, disagree and prove me wrong. No guy that I know of can engage an executive in a short skirt, with some stiletto heels and a low cut top at a bar better than a woman. Male social engineers will typically target, if there is a choice, females. Unless the "attacker" is significantly tuned into the social engineering game, males attempting to extract information from other guys is slightly more difficult. Sex sells, so does alcohol...put the two together and it's game over..why do you think strip clubs, pornography and alcohol are still around....

Yea, this should be addressed in training. Though I've found that discussion of sex and alcohol walk a thin line with some entities. Because you know. God forbid the truth be told and we discuss such "taboo" subjects...seriously, get off the damn high horse...

The most common method social engineers will use, is the telephone. This has as of late been coined Vhishing. For the record, I hate the mass media for diluting the common definition and trying to create new coined phrases to address one portion of the social engineering attacks. Doing so only confuses the issue, so to the guy who made the phrase Vhishing..I hope you get a gaping paper cut and someone dumps lemon juice on it. Anyhow, when creating the social engineering defense training program this must be included in it. It must also be included in the organizational operations procedures along with the required methodology for reporting suspicious phone calls. One thing I recommend in my training on social engineering defenses is should any employee on the phone feel a call has become questionable, engage the internal security team. Let them deal with the phone call and have the employee remain on the line in silent mode, acting as on the job training. These types of encounters should also be included in the internal security training.

Training is where it begins, the training has to be realistic though. Chris Nickerson probably gave one of the best realistic training scenario's when he stood on stage and morphed himself though numerous different personalities without any interruption between each transition. Bearing in mind of course that Chris is an exception to the rule and most social engineers are not at that level of manipulation..yet anyhow.

So what is the point of this you're likely asking yourself at this point. We're establishing the framework for the defense. The defense will typically develop itself in some type of training, whether it be formal or informal. In my experience, executives have been the least receptive to this training. Why, because they feel that they are not able to be manipulated due to their intellectual superiority. If you're an executive and you are reading this and you fall into that category; sorry, you are not superior you are just plain stupid. The most receptive to training have been the line level tech support and engineer type personnel. They are also aware they are typically the individuals being targeted.

The telephone was given much press recently with the DEFCON Social Engineering Contest. This was both a success and a failure. The contest itself was a success as it gave further proof that social engineering as an attack vector is still possible, I know..as if this needed proof right..I`m being gentle. The failure however, was not with DEFCON or the contest, but within the Public and Private Sectors in response to this. In speaking with several people about this, there were a flurry of internal communications just before the contest went off. In general, this is what social engineering is, they use a phone..don't release any information. For real...this is not training people. The other failure was there was, at least to my knowledge, no follow-up training. It was more of a yea, it came..it went..status quo..

FAILURE

Email and IM are other popular methods, email taking the most frequent over IM though. Everyone is aware of it, and amazingly many people are still happy to click on that link or open that email attachment. Again, include the attack vector in your training. There is nothing more annoying than that HR executive click on a link to learn to "optimize" his staff, load the java applet which pushes the reverse shell to some system in china. No names here of course...you know who you are...

Face-to-face encounters, in there numerous forms, are by far the most effective next to the phone calls. We are human, we like to interact, we like to be helpful. Hell, I`ll admit it, I got engineering by two guys last week sitting in a room talking techie..of course it wasn't till after we finished the conversation that I said to myself..shit..I got punk'd. Technical security people are few and far between, we love interfacing with others in the field. Don't fall prey, the training should reflect as such. Never release any interesting information, duh..even me. I admit my flaws..can you =) Good social engineers will flourish in the face to face encounters, smooth talking, well versed in various operational functions from accounting executive to janitor..switch your personality on the drop of a dime. In the end, if the identity of the individual cannot be verified, remove them from the facility. You training and procedures should dictate as such. This is also a requirement under several regulations such as PCI^[?].

General conversation is a relatively easy route, especially when targets are more than happy to speak about sensitive information with their colleagues on the phone or on the Metro/Subway. Loose lips sink ships people..seriously close them. Shoulder surfing falls into this as well. If you're reading, writing discussing it in public you're jeopardizing the security of the information. Address it in the training, enforce and reprimand on violations. Social Networking I like to dump in here as well, don't type it if it doesn't belong there. Training to address the insecurities of social networking sites, their lack of security and privacy as well as the vast methods to obtain the information on these sites....train train train..oh, policies covering it and enforcement of those policies.

Piggy-backing is still very popular, even in highly secure locations I've used this very recently. The smoker, the lost-soul, the I lost my card..all must be addressed. The training and policy must reflect the importance. Employee's must learn to confront those who do not appear as an identifiable badged employee, must confront those with no ID, require internal security to be contacted to verify those who fall into the suspicious. Those employee's allowing others to piggy-back must be reprimanded, even terminated. Again, policy is only as good as the enforcement. If your training and policy state one thing, the enforcement must follow or the policy and training are useless.

Dig through the crap, yes I mean that literally. I have on some occasions, prior to giving a training session, went through dumpsters a day or two before the session was to begin and bring with me any interesting information I found. Of course the interesting information ranged from credit card numbers of customers to ACH transaction receipt with the full account numbers tossed right into dumpsters. On other occasions full medical records of patients who have switched doctors. If you were one of those customers by the way..I love you for making my job easy and I hate you for not following your own policies on the proper disposal of information..but I mean that in the most endearing way =) Also, interesting information can include other tidbits like business cards of vendors..

This was not meant to rehash the overabundance of articles detailing common tactics. This is meant as items you need to address, and that I address, in the internal training programs.

Social Engineering Training
-What is Social Engineering
-How does it occur
--Phone
--Email/IM
--Face-to-face
-Internal Security Team Intro and Points of Contact
-Procedure on reporting Social Engineering Incidents to the Internal Security Team

If your internal policies and procedures do not address Social Engineering in its various states, or you do not have internal policies, now would be a good time to start on that project. If you lack the internal policies and are looking for templates, SANS has a template repository online..check it out.

The policies must address what Social Engineering is from a high level as well as the penalties for not complying with the possible. The defined penalties must be both accepted by executive management and enforceable.

The procedures must be explicit in this is what you need to do if you feel you are the target of a social engineering attack. The procedure must of course reference the policy to note the potential repercussions if the employee does not abide as well the potential impact to the organization for non-compliance.

Policies and Procedures are only as good as they can be enforced..and they must be enforced or they are useless. The training must be as realistic as possible and note the importance for compliance with the policies and procedures. Any deviation will result in a failure of a portion or the entirety of the program.

Follow-Up: Commentary: Cybersecurity Needs Public Notice

nospam@example.com (Keith Pachulski) — Sun, 08 Aug 2010 11:00:18 -0400

Praise to Sheldon Whitehouse in this article. While not overly technical, it does touch on some important issues from the 10,000 foot view. While the issues he discusses are by no means new, they do however continue to plague the industry as a whole.

Commentary: Cybersecurity Needs Public Notice

I especially love his analogy of how we should treat our computers and network like our cars. Country depending we all drive on the same side of the road, follow basic rules of driving and for the most part we allow for common courtesies. The occurrences of ill behavior are for the most part minimal when viewed in comparison to the overall populous. And of course when we don't obey those rules there is the chance that we will be met with the flashing lights in the rear view mirror, for the remainder of the population, police omnipresence appears to work as intended.

On the flip side, he looks at how we operate our systems. Nice overview, and I`ll add a few comments to it.

Overall written policies, procedures and regulations continue to fail us. It is not because the documents themselves are failing but because of the executive/administrative and enforcement parties responsible for them do not follow through. Anyone who has sat through my classes or speeches knows this phrase all to well, the same others in my field have stated:

-- Any policy and/or procedure that is not backed by the executive or administrative bodies isn't worth the paper it is written on. Any policy and/or procedure that is not enforced on all individuals within said organization isn't worth the paper it is written on.

It does not matter if you have policies and procedures written to address every conceptual risk, if you, or the executives in your organization, are not going to enforce them. Stop writing them and go bury your head in the sand, wait..it's likely already been there so ignore that last sentence.

Basic precautions are great to say you have; yes we have an Anti-Virus (AV) installed on all system, they automatically update, we have NIDS^[?], we have HIPS, we have Firewalls. That's great an all, but while the commercial security vendors are making out on this deal, the public and private sectors are the ones suffering for the true lack of protection. Any signature based software/hardware will only catch approximately 70-80% of the known threats. This of course includes a major portion of the AV, NIDS, HIDS^[?] and HIPS deployments in production. This excludes those anomaly based systems, which are nice but require more manpower to properly use. Due to that, anomaly based systems are rarely placed in production environments.

With those basic precautions there is also the issue of reliance on automated systems to report events. Many of these automated signature based systems are placed into the production environments, never tuned, and simply spew mass amounts of noise to a console that an untrained or under-trained individual sitting at a console is expected to process.

Information sharing has been a hot topic for years. Several private and public sectors have developed lists and groups to better share information amongst themselves. These have fallen into typically two distinct classification, information groups that disseminate verified information or information groups that have either verified, not verified or partially verified the information. Access to these groups ranges from relatively easy to gain access to, to nearly impossible unless you're in the "elite" clique.

Of course, the easier the access to the information, typically the less reliable the information. There is also the chance of disinformation which of course may negatively impact the monetary and operational ability of organizations. I'm not going to go too much into this right now. Brian Martin is working on a paper regarding this so I'll let him have the glory on this topic *waves to Brian*....cough..Starbucks...

A good question that should be posed within the conclusion of this should be, what should the general public be required to report? There seems to be much onus placed on the government to report to the citizens. Why should the citizens not be required, by law, to report incidents of system compromises? Personally, I think there needs to be a state/federal funded group that receive reports of system compromises.

Recommendations:

Information Sharing groups/lists, with verified members, allowing for the dissemination of accurate information. Clique groups are nice to fluff ego's but don't help the overall community. Drop the egotistical bullshit and start helping everyone out.

Reliance on automated signature based systems continue to plague us. While it's nice to have the pretty SIM with with all the pie charts and crap, they typically are not configured to actually generate any useful information such as full packet dumps. I blame this mostly on the fact that training on the underlying systems is severely lacking as well as training on the actually traffic triggered events. Vendors in their default "recommended" configurations do not log all the interesting information, but they can sure spit out a shitload of alarms to make the interface look as though it was worth the 85K it cost the entity to buy it.

The big one is policy and procedure. When I say this I don't target this only at private/public entities with focus on their specific user base. I also target this at the service providers dealing with their masses of customers. If your AUP/EULA states X, and the customers violates X, there must be repercussions for said activity. Same with the private/public sectors, if you have policies and procedures in place and any user, including the executives, violates those rules, there must be swift and open repercussions for those actions. If there are no actions for violating the rules, the rules are useless.

Ok, I'm done ranting for now..only because my nephew just shot water all over my laptop...

RANT: Non-existent 'analyst' befriends security experts

nospam@example.com (Keith Pachulski) — Mon, 26 Jul 2010 08:38:43 -0400

Wilson Rothman, further proof of three things:

1) Journalist are struggling to find "good" content to write about
2) Mainstream technology journalist rarely know what the hell they are writing about
3) a Communications degree isnt worth shit

I'll try to do the positive side first. Ok you're communicating something interesting to the masses..good job you've succeeded.

Ok, enough of that...

Too bad this story was already over a week old in the mainstream when you found it and decided to rehash it, put your name on it and.

He, Ryan, did not prove or disprove the "fragility" in social networking security (Side note: when you use phrasing like "social networking security", try to clarify what you mean exactly. That vague statement would be comparative to me saying "I own a car" - that's nice, what kind of car is it, does it have wheels?). All he proved is that social engineering is still viable, it is an old concept that for whatever reason the masses still do not grasp or recognize even though security professionals try to make the angle well know in security awareness training. My suggestion to Rothman or anyone else who has never heard of social engineering or still doesn't know what it is..google..is your friend..or hell..wiki for social engineering..it is not a super secret.

Some security guy played a common ruse that has been used numerous times before, hell I've done..any security professional who has ever engaged in a posture assessment or penetration test has used the same angle in varying degree. Nothing new to see here..these are not the droids you are looking for...

I`m curious about one statement though, which he makes appear as a question "So, she started hacking at age 14". Did he seriously find this odd? Most of the people I know that have been doing this for life started "tinkering" well before age 14. I was 11 when I "hacked" my first network. My one son is 7; he has already figured out how to do some really creative security bypassing so he can play on blockland without dad knowing.

blah yea..I`ve already spent way too much time than deserved on this rant

//rant off

RANT: Do Cyber-Attacks Require a 'Duty to Assist'?

nospam@example.com (Keith Pachulski) — Sun, 18 Jul 2010 11:29:37 -0400

When I first read this article by Duncan B. Hollis and David G. Post, I snickered..ok so I laughed heavily. This is one of those that displays the true disconnect between the legal and technological arms of the industry. I applaud their efforts in writing this, but from both a technical and administrative perspective there is much further thought and guidance needed if something like this were to be implemented.

Do Cyber-Attacks Require a 'Duty to Assist'?

Let me begin by saying that you cannot use standard military operational tactics to address attacks with targeted count-attacks. Unlike the "real world" where we can deploy a small ground group to neutralize a hostile target, the same cannot be done on the internet. Relaying and swiveling through numerous hosts is a common tactic and to simply say we'll just neutralize all the intermediary points till we find the true source would be akin to deploying a FORECON DAP to terminate the dwellers of all residences where a hostile long range marksman temporarily resided until they determine his finale location.

While this would be an amusing approach, at least for me, to deal with internet based threat^[?]-sources in this manner of surgical disarmament, it is by no means realistic.

To begin to develop/create this type of international response, it must be realized first that this would imply that a simple portscan from a hostile national would be considered an act of war. Are we seriously considering to escalate to this type of required international response? I highly doubt it. And at what point does an internet based counter-attack transfer from an internet counter-attack in response to an SOS to the release of ground troops? Escalation always occurs, it's a matter of course. If people can't fix something one way..a group of men/women with heavy arms for easily resolve the issue.

Citing international law on SOS transmissions then comparing those to internet based "attacks" only shows a severe lack of technical understanding or comprehension of what various groups/nations/governments consider to be attacks. There is not, at this time, a definitive internationally accepted standard of what is or is not considered to be an attack. Nor are there internationally accepted standards on intrusion analysis, incident response or threat-based counter-attacks. As many of you are aware, every commercial and governmental agency in this country has their own definitive guide on what they consider to be attack as well as their own custom response guidelines and procedures in addressing those. And then there are the slew of others that have absolutely no response guidelines or procedures.

We as a country alone are still very fragmented in trying to address the internet based threats/risks within our own borders, our own governments and our own companies. I do not believe at this time this type of view should even be considered or entertained. Hell, we can even stop people from taking laptops out of sensitive facilities, transporting classified information, and leaving them in their vehicles for their laptops to be stolen while they "just left it alone for a second".

Here are some of the reasons I believe this type of dream is not realistic...

-There is a continued lack of proper training throughout the information security industry.

-A great percentage of the certifications and degree's do not create professionals, they simply create bookworms with pretty letters behind their names.

-There is a continued lack of policy, procedure and documentation of our infrastructures.

-I would be willing to wager that greater than 80% of the public facing firewalls deployed would not stop a motivated/funded attacker.

-Intrusion detection/prevention systems are typically misconfigured and perform no relevant function other than making pretty graphs.

-A large percentage of attacks go unnoticed, see my first sentence.

-There is a lack of executive understanding of the threats, as such, funding to correct some of these issues is mistakenly diverted to other area's that actually generate revenue.

-Managed Security Service Providers (MSSP's) for the most part do not effectively provide the needed services to their customers due to budgetary constraints on providing services to far too
numerous customers.

-MSSP's typically go for the cheapest possible alternative to retain the bottom line, this includes both personnel as well as hardware/software (they do however have cool tools that make pretty pictures).

-The previous two sentences also applies to many local/state/federal governments that retain their own internal security groups.

-We rely too much on anti-virus to save us. Anti-virus is simply a stop-gap technology with a proven track record for not being overly useful.

-Automated systems save us money, but they are just that automated. A perl script parsing a log file is not a human with 20 years of experience.

How does all this apply to the original authors article?

Unless there are standardized methods and procedures, there will be far too much fragmentation internationally for any type of globally accepted response to internet based attacks. Until there are globally accepted standards to address those few issues, which are only a few needing to be addressed, there could never be this type of response.

At least in the opinion of this security guy =)

Follow-Up - Responsible Disclosure (RANT)

nospam@example.com (Keith Pachulski) — Wed, 07 Jul 2010 19:54:44 -0400

Listening to a podcast on the way home from work, the topic of responsible disclosure again came up. I can't tell you how much I absolutely tire of hearing this topic discussed. The thing that really irritated, no not irritated, pissed me off though about this is that one of the individuals was stating something along the lines of there is no responsible disclosure and that Full Disclosure is the way to go.

Here is my issue with this. There is already a thin line that separates the security professional from the individuals we as professionals strive to protect our employers from.

Black hat, white hat, gray hat..gimme a break already

If you're a black hat, it is obvious of your stance on vulnerability^[?] disclosure; you only care about making a name for yourself regardless of the consequences of releasing details and exploit code to show the existence of the vulnerability and how to leverage the vulnerability to gain access to systems to which those black hats, script kiddies or foreign nations do not have the authorization to access.

If you're a white hat, you follow the proper moral and ethical path and properly notify the vendor before releasing the details to the general public. Your concern is with protecting your employer, customers or the national infrastructure. I applaud you...

If you're a gray hat, you need to just realize you are no better than the black hats only out to make a name for yourself because you're confused or just feel you're better than everyone else..seek professional help...

As sexy and “cool” as Full Disclosure may be to some people, how does it help the community? How does releasing the details and exploit code for a vulnerability assist the vendor is developing and testing a proper fix? How does Full Disclosure protect our employers, our customers or our national infrastructure?

Here are the answers, it doesn't take a freakin rocket science to figure this out. Releasing details for an exploit or releasing code before properly notifying the vendor and allowing for the development of a fix forces the vendor to push out a crap fix just to address the specific flaw that someone released to the world. Of course in doing this, you get a band-aid that may correct the the specific flaw and introduce others due to improper QA on the fix. Say it with me now...Band-Aid. News Flash, Band-Aids fall off...

Releasing the details and exploit code potentially jeopardizes companies and governmental agencies, due to the exploit code being pushed to script kiddies and hostile foreign nations well before the vendor can properly push the fix. Even after a fix is released from a vendor, most modern companies/agencies then have to put the fix through internal testing and validation to ensure the fix doesn't impact the operations of the affected server or the software application.

Even best case of a rushed vendor release, you're talking a week at best for the vendor to go into rush mode to develop and push the fix then another week to two weeks for the users of the vulnerable application to receive and test the fix. This leaves a potential gaping two week window for exploitation of the affected service..

Seriously people, if you are a professional in the security field and you work to protect your employer and/or customers...stop talking and think about the words that come out of your mouth and into the podcasts or onto the websites..

I understand the point of saying...oh Full Disclosure..force the vendors to stop pushing bad code by exposing their flaws...but at what cost to prove that point? Are you as a “white-hat”, ethical security professional going to potentially expose PII or classified governmental information just to poke at a vendor and make fun of them in your next Defcon/Blackhat/B-Sides presentation?

/rant off

Responsible Disclosure – For real?

nospam@example.com (Keith Pachulski) — Tue, 29 Jun 2010 20:36:31 -0400

It seems as though we as an industry having been having this debate now over what is consider to be responsible disclosure for as long as I can remember. For whatever reason though, this topic seems to once again be picking up some focus again as I`m hearing about it in podcasts and seeing more of it on some websites. Why, I`m not entirely sure. Personally, I think this is a horse we've spent more than enough time beating on and that beast needs to just be put to sleep already.

In my own view of this, it's real simple. When we, as a community, discover a defect in a piece of code, we need to take the high road and work with the vendor to allow them a reasonable amount of time to offer a fix to the general population. As I say that though, there are some side thoughts to bear in mind with my own personally recommended process.

Once you have discovered a flaw and can both provide documented proof of the defect, you must be able to repeat the documented process for how you exploited the flaw. Exploiting a flaw, not remembering how you did it with no repeatable process, than spamming a vendor and expecting some resolution without providing any useful information deserves you nothing but a kick in the /bleep/.

Designate a timeline with the vendor. This timeline should include a reasonable amount of time for the vendor to respond to your report, develop a fix for the defect, test the fix in their own test environment, schedule a release date of the fix and finally when you as the “discoverer” of the defect can announce the discovery and resolution of the flaw.

Any deviation from the timeline must of course result in some repercussions. If the vendor deviates from the timeline without proper communication, all bets are off and I would personally release the information to the world. If you deviate from the timeline without proper communication to the vendor, the vendor should have the ability to pursue civil and/or criminal action against you.

I use the word reasonable often, and with good reason. A reasonable amount of time for a vendor to acknowledge receipt of the reported defect in their software, in my opinion is no more than two weeks. Anything outside of that I consider to be stonewalling. A reasonable amount of time for a vendor to verify the existence of the defect in their software is no more than two weeks after notification. A reasonable amount of time for a vendor to perform their development and testing of the fix for their code is no more than one month after notification.

You'll note that no where did actually state that the vendor must respond to the notification. Should the vendor choose to respond and create the timeline, wonderful. However, lack of response from the specific vendor then sets the timeline to whatever you as the discoverer of the flaw feel appropriate. Bear in mind though that the release of any exploit code against a software defect may result in some negative feedback from the community as a whole if you intentionally did not give a vendor adequate notification or time to resolve the issue.

For historical reasons, these are the two more popular generally accepted “Responsible Disclosure” practices along with a brief overview of each.

CERT Vulnerability^[?] Disclosure Policy (VDP)

The CERT VDP is of course referenced the most due to the popularity of the CERT/CC. Their stance is likely one of most aggressive of the surviving VDP's today. Within the CERT/CC VDP, once CERT receives a vulnerability^[?] notification. CERT notifies the affected software vendor immediately upon receipt of the vulnerability notice. Included within the notification to the vendor is the contact information for the individual that reported the vulnerability, unless of course the individual requested to remain anonymous. 45 days after the receipt of the notification by CERT, they will publicly announce the details of the vulnerability. During the 45 day window, CERT will maintain communication with the individual who reported the vulnerability.

Rain Forest Puppy Vulnerability Disclosure Policy

Rain Forest Puppy, oh how I miss this guy...RFP's VPD was created with a slant empowering the researcher than the vendor.

The researcher notifies the vendor of the vulnerability. If the vendor does not reply within 5 days, the researcher is free to release the vulnerability information to the public. If the vendor does reply back to the researcher within 5 days, the researcher should assist the vendor to replicate and remediate the vulnerability. During this time frame, if there is no communication from the vendor to the researcher for a 5 day period, the researcher is free to release the vulnerability information to the public. Once the vendor has developed a fix/patch for the software, the vendor should communicate as such to the researcher. The researcher and the vendor will then jointly develop the disclosure statement.

Whichever method you decide to use, bear this in mind - Each of us has a responsibility to the entire community. One person acting selfishly can easily cause a black-eye to the entire industry. Respect the rest of us and simply communicate..

RANT: Missing records on stolen laptop from Cincinnati Children's Hospital

nospam@example.com (Keith Pachulski) — Sat, 29 May 2010 16:22:49 -0400

At what point do the people of the U.S. have to hear this enough to start taking some legal actions against the medical providers. I don't have enough fingers and toes to count the number of times over the past year that I've seen this type of headline or heard the statement uttered that yet another medical facility has lost more personally identifiable information (PII).

I absolutely love this quote, in a sarcastic manner of course - "We need to and are doing a better job of strengthening our encryption practices," Feuer said

Really, do you think you need to do more..oh and Feuer, it's obvious that you are not doing a very good job at well..doing your job.

Originally HIPAA^[?] did not require the use of Whole Disk Encryption (WDE^[?]) on laptop devices, that has thankfully changed and is now a required under the revised security rules.

WDE is not expensive or overly difficult to roll out technically or administratively. It's just a matter of being lazy and saying "that will never happen to us". There are a number of good solutions out there ranging from free (TrueCrypt) to commercial (PGP Desktop with WDE).

Of course, the real blame here is going to come down to the OCR/HHS (Office of Civil Rights/US Dept of Health and Human Services). The old saying of a policy that is not enforced is not worth the paper that it's written on. Start cracking down and punishing them in the wallet and more organizations will take the HIPAA Security and Privacy Regulations seriously. I know of more than my fair share of those types of organizations who knowingly do not comply and find the entire "thing" laughable. To quote one hospital IT administrator "I have no intention of becoming HIPAA compliant, and when the day comes that we get audited I`ll simply quit and find a new job".

Missing records on stolen laptop from Cincinnati Children's Hospital | cincinnati.com | Cincinnati.Com

Vulnerability & Patch Management - My Two Cents and recommendations

nospam@example.com (Keith Pachulski) — Sat, 29 May 2010 11:00:57 -0400

I’m on a vulnerability^[?] management and patch management tangent. No real reason why other than I was listening to a podcast and a comment irked me so I decided to write this up. This is a high level overview of my recommendations on implementing a program. As always if you have any questions on this feel free to ping me.

Identification of Assets

For whatever reason, I find this to be one portion of any vulnerability management process that continues to fail whether it is private or public sector. Network and Systems people love to turn up new technology but they typically do not want to generate any documentation on what the system is, who is responsible for it, what applications are installed onto the system and if some other person is responsible for those installed applications. This is a critical step to being capable of performing any type of vulnerability management.

Vulnerability^[?] Identification & Tracking

Vulnerability identification can be discovered from many sources including risk assessments, vendor notifications, open sources of information (exploit-db, securitytracker, packetstorm, etc) or vulnerability assessments through automated tools (Nexpose) or manual assessments (Penetration Testing, Risk Assessments).

Vulnerability, in itself, is a broad term. Vulnerabilities can be initially discovered pre-production through system or application configurations such as running an outdated version of MySQL or allowing connections from public facing systems to protected internal resources. These types of pre-production vulnerabilities must be documented in the Identification of Assets phase.

Vulnerabilities discovery through commercial sources or clearing houses are typically assigned a criticality grade or score (CVE^[?], CVSS^[?], Critical, Medium, etc). Those vulnerabilities that have been discovered from open sources, to which commercial or clearing houses have not process, you must review and assign a grade to the vulnerability. Based on the grade or score, coupled with the criticality of the systems that may be affected along with the probability of exploitation, we can then properly gauge the response to remediation.

If you are unsure of how to perform the grading on your own, or just want a quick and dirty, the DHS^[?] has made available a CVSS v2 Calculator available at the following URL:

• http://nvd.nist.gov/cvss.cfm?calculator&version=2

Vulnerabilities discovered after deployment must be tracked from discovery to remediation. This is heavily reliant on some type of internal tracking system, personally I use redmine, to track the lifecycle of the vulnerability from the time it is discovered, the entire internal review and assessment, recommended corrective actions, implementation of remediation action to verification and finally the lessons learned or RCA^[?] (root cause analysis). On a side note, any remediation actions must be included in the system documentation. This will assist in not on the vulnerability/patch management process, but will also greatly improve incident response timelines when necessary.

Response Planning

When new vulnerabilities are discovered, a response planning process should be engaged. As part of the response planning, the focus should be on the specific vulnerability as well any risks identified during the internal review and assessment. Once a new vulnerability has been discovered, there is of course a greater chance of exploitation of the vulnerability. The planning process should of course involve the incident response team but must also include the system/applications owner(s) as well as the applicable operational group (i.e networking, systems administration).
Vulnerability Remediation

At this point in the lifecycle, we’ve identified the vulnerability, identified the vulnerable systems, developed a remediation plan, engaged the incident response capability and are ready to implement the chosen solution. Prior to actually correcting the vulnerability, ensure the system/application owner(s) have been properly notified. Included within the notification must be the projected time frame to begin as well as conclude the corrective actions. Make sure the notification includes all applicable individuals so no one feels left out, this has come back to bite more than one handler.

• You’ve also created your back-out plan and you’ve also run the entire corrective and back-out past the system/application owners right? =)

Keep in mind that the chosen remediation method must follow the documented process previously defined and agreed upon. This process must be adhered to by all involved parties. Any deviation from the process must be authorized, if for some reason the deviation does not allow for authorization at the time, the reasoning for the deviation must be documented and the affected parties later informed of the deviation in totality.

Remediation Methods Overview

Remediation methods are typically classified into the following three:
• Installation of a security patch
o Application of security patches may replace specific portions of the application code that have been determined to expose a vulnerability

• Modification of a system or application configuration parameter
o Modifying the configuration of how the application, or a portion of the operating system, functions that has been determined to expose a vulnerability

• Removal of the affected application or service
o If, after thorough review, it is determined the vulnerable piece of software, or portion of the underlying operating system, is not a functional necessity of the system, the software or service should be removed.

Remediation Methods

1. Installation of the Software Patch
a. All software patch testing should be performed on non-production systems.
b. Verification should be performed to ensure installation of the most recent security patch does not inadvertently remove previous security patches.
c. If multiple patches were published, verify there is not a specific installation sequence.
d. Prior to installation of the patch, ensure that any applications that may rely on the portion of the application, or operating system, have been fully tested to ensure continued operability post patching.
e. The length of time to properly verify a patch or subset of patches is variable based on the scope of the patch and whether the patch will interact with subsets of the operating system or other applications. The exact time frame of patch testing must be defined by the parties responsible to the systems/applications to be patched as well as the group performing the testing.
i. Security patch installations should additionally be implemented into baseline operating system installation procedures.
f. Manual verification of the security patch should be performed through the use of an automated vulnerability assessment tool (Nexpose) or manual verification.
g. Once testing of the security patch has been completed, the patch(es) are to be introduced into the patch distribution system (i.e. SCCM) for dissemination into the environment.

2. Modification of System or Application Configuration Parameters
a. Modification of configuration parameters has traditionally been a “from the hip” response to a vulnerability, as such they typically do not receive thorough testing as security patches.
b. Configuration modifications should first be performed on non-production systems. Configuration modifications may impact operational privileges and in some cases functional stability. As such, post implementation of configuration changes should include monitoring the system/application for proper functionality and stability.
c. Manual verification of the security patch should be performed through the use of an automated vulnerability assessment tool or manual verification.
i. Configuration modifications, when permanent, should be implemented into the baseline operating system and/or application installation procedures.

3. Removal of the Affected Application or Service
a. Removal of the vulnerable application or service effectively eliminates the vulnerability. Prior to removal of the application or service however, a thorough analysis of the system and applications in operation must be performed to ensure that removal does not impact the operational requirements of the system.
i. Just because you think java is not needed on that server running Oracle 11gr2, from your perspective; realize that in doing so you may make that Oracle Enterprise Manager or Grid Control application stop functioning completely.
b. Removal of applications or services, as with patching, should be performed on test systems. A pre-defined period of time should be stated for review of the operational integrity of the system post removal.
c. Manual verification of the security patch should be performed through the use of the Vulnerability Assessment tool.

A final option, typically utilized by Governmental agencies, would be the issuance of a RAF^[?] (Risk Acceptance Form). The RAF neither mitigates nor eliminates the vulnerability, but indicates that the system/application owner recognizes that a potential vulnerability exists, acknowledges that no changes to the system will occur and accepts the potential risk. In my personal opinion, this is an option that should rarely, if ever, be utilized.

• Something else to bear in mind, the entire remediation process should follow your organization change management process..you do have a change management process right?

Remediation Verification

Upon completion of the selected remediation effort, verification must be performed through manual review of configuration files or patch installation logs and vulnerability assessments. It is my personal recommendation that systems/applications which have had some corrective measures made against them be monitored for at minimum one week to ensure system/application integrity and availability.

Rant: Privacy is Dead, Thank the Internet - Firing dispatcher for Facebook drug joke

nospam@example.com (Keith Pachulski) — Tue, 25 May 2010 13:16:00 -0400

This one really boggled my mind, though really it shouldn't have. Dear interweb users, the information you put into Facebook, MySpace, Twitter or the other slew of social sites out there IS NOT PRIVATE. Contrary to what those sites tell you, they do not nor ever will care about what you think is private or what the outcome of exposing certain sensitive information to the world will be. They will not care if you get fired, divored or or or.

I've on occasion been questioned as to the amount of information I put onto twitter which then gets replicated through to other sites automagically such as yahoo, facebook and linkedin. But from my perspective I treat that information the same way I treat a system that gets dropped into a DMZ. As soon as I place it there I accept the fact that if the system hasn't been compromised, it will at some point therefore I do not place any sensitive information into those systems. With that, I realize that anything I put onto any social network will become public information. Not only will it become public, but it will remain public for as long as the internet will likely remain in existence. As soon as it hits those social sites, it will at some point be cached into every search engine in operation as well as scoured by a horde of search bots looking for interesting tidbits of information.

With that said, stop typing and engage that mass between your ears before your fingers start walking across that keyboard. Anything you put up there can, and will, at some point in your life come back to haunt you. If you just type random crap and hit post, along with those unsuitable jokes you wouldn't want your boss to see, the pictures of you and you f#&% friend you wouldn't want your spouse to see or the slew of other stuff you wouldn't make known to the general public, then you deserve whatever happens to you =)

But hey, this is just the opinion of another security guy tiring of repeating the same stories to the same crowds about people doing really dumb things on the internet then crying "but I didn't know" when it blows up in there face. On the flip side however, keep it up...you continue to provide me with great stories for the training sessions I do /smirk/

/rant off

Firing dispatcher for Facebook drug joke was right, Wisconsin council claims | News.com.au

Rant: Rogue botnet shut down by US government body

nospam@example.com (Keith Pachulski) — Tue, 25 May 2010 13:03:57 -0400

While I applaud the FTC^[?] for taking the initiative on this problem, in the back of my head I still have to wonder this though; why does the commercial sector still have to rely on the US Gov't to deal with this problem. Why did the upstream provider not simply pull their feed, blackhole their netblock and communicate the reasoning to the community.

We, I use the term collectively as the individuals who run and oversee the internet operations in the US, need to address these types of activities more ourselves and stop relying on the government. The more we rely on them, the more laws that are going to be enacted to address these problems which is in turn going to impact how we will be forced to run our businesses on a daily basis.

It amuses me that we do not want to deal with this ourselves, but we're quick to bitch and complain when new laws are passed that force us to deal with it.

In closing to all the providers out there, start being more proactive in your responses to abuse complaints such as those that focused on 3FN type activities or STFU when laws are passed and you start getting fined for not being proactive in the first place

/rant off

Rogue botnet shut down by US government body

UPDATED - Money Laundering - The Next Generation

nospam@example.com (Keith Pachulski) — Wed, 28 Apr 2010 22:56:46 -0400

Blog Update: I was directly contacted by one of the "security' personnel from constantcontact. They wanted to assure me that the account in question which had sent these emails had been terminated.

It's amusing at best that money laundering was once something that was kept secretive, in the current generation the launders now actively and openly seek out via spam low end money mules.

Full Email Body Content

Dear Keith Pachulski,

We found your resume on {board removed} . For more than 20 years makes its business by working with non-standard banking services around the world. We are expanding our company and provide a list of new services in the United States. Transfer of money for non U.S. citizens with the US check is one of our new services . For this reason our company has some vacancies, of Manager in USA.

Requirements
-US citizenship
-You should be at least 30 years old
-At least 2 hours of free time a day are necessary
-couple of working hours

Your responsibilities are:
-cash this check
-transfer money to the customer the way he/she chooses

To make a special formed reports on the carried out work for every check

Your benefits :
-salary of at least 8000$
-the income of 50 $ - 300 $ per day
We take care of all the taxes on the transactions you carry out.

If you are interested in the vacancy, please provide us with the following information:
-Your age
-State of your residence
-Contact phone number and the tie when we may contact you (provide your mobile phone number).

Full Headers from Email

Return-Path:
Delivered-To: {email address removed}
Received: (qmail 5776 invoked by uid 89); 28 Apr 2010 08:16:02 -0000
Received: (simscan 1.4.1 ppid 5680 pid 5692 t 2.9715s)
(scanners: spam: 3.2.0 clamav: 0.90.2/m:43); 28 Apr 0110 08:15:59 -0000
X-Spam-Checker-Version: SpamAssassin 3.3.1 on {my server removed}
X-Spam-Status: No, score=3.2 required=8.0 tests=BAYES_99=3.5,
FREEMAIL_FROM=0.001,FREEMAIL_REPLYTO_END_DIGIT=1.151,HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001,RCVD_IN_IADB_DK=-0.095,RCVD_IN_IADB_LISTED=-0.001,
RCVD_IN_IADB_OPTIN=-1.47,RCVD_IN_IADB_RDNS=-0.235,
RCVD_IN_IADB_SENDERID=-0.001,RCVD_IN_IADB_SPF=-0.059,T_ADVANCE_FEE_3_NEW=0.01,
T_TO_NO_BRKTS_FREEMAIL=0.01,URIBL_GREY=0.424 autolearn=no version=3.3.1
X-Spam-Level: +++
Received: from ccm39.constantcontact.com (208.75.123.164)
by 0 with SMTP; 28 Apr 2010 08:15:59 -0000
Received-SPF: pass ((null): domain of ESC1103346610741_1103344271711_1500@in.constantcontact.com designates 208.75.123.164 as permitted sender) receiver=(null); client_ip=208.75.123.164; envelope-from=ESC1103346610741_1103344271711_1500@in.constantcontact.com;
Received: from p2-jb501.ad.prodcc.net (unknown [10.252.0.103])
by ccm39.constantcontact.com (Postfix) with ESMTP id CB6B823900A2
for {email address removed}; Wed, 28 Apr 2010 04:15:58 -0400 (EDT)
Message-ID: <1103346610741.1103344271711.1500.1.11041518@scheduler>
Date: Wed, 28 Apr 2010 04:15:58 -0400 (EDT)
From: Samantha globalnewbusiness
Reply-To: globalnewbusiness1@gmx.us
To: {my email address removed}
Subject: job offer
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_3005027_1552086054.1272442558826"
X-Mailer: Roving Constant Contact 2009 (http://www.constantcontact.com)
List-Unsubscribe: http://visitor.constantcontact.com/d.jsp?p=un&v=001vP4uirOIyh35lN44xphGYhnEF2BT-6dfX7coxuBLAjNG50XLJ2ddAg==
X-Return-Path-Hint: ESC1103346610741_1103344271711_1500@in.roving.com
X-Roving-ID: 1103344271711.1500
X-Lumos-SenderID: 1103344271711
X-Roving-CampaignId: 1103346610741
X-Roving-StreamId: 0

Whois Information

OrgName: Constant Contact, Inc
OrgID: CONST-21
Address: 1601 Trapelo Road
Address: Suite 329
City: Waltham
StateProv: MA
PostalCode: 02451
Country: US

NetRange: 208.75.120.0 - 208.75.123.255
CIDR: 208.75.120.0/22
OriginAS: AS40444
NetName: NET-CC1
NetHandle: NET-208-75-120-0-1
Parent: NET-208-0-0-0-0
NetType: Direct Assignment
NameServer: NS1.CONSTANTCONTACT.COM
NameServer: NS2.CONSTANTCONTACT.COM
NameServer: NS3.CONSTANTCONTACT.COM
NameServer: NS4.CONSTANTCONTACT.COM
Comment:
RegDate: 2007-02-22
Updated: 2009-12-17

RAbuseHandle: ABUSE1897-ARIN
RAbuseName: Constant Contact Abuse
RAbusePhone: +1-781-472-8103
RAbuseEmail: abuse@constantcontact.com

RNOCHandle: CCO156-ARIN
RNOCName: Constant Contact Operations
RNOCPhone: +1-781-472-8103
RNOCEmail: arin@constantcontact.com

RTechHandle: CCO156-ARIN
RTechName: Constant Contact Operations
RTechPhone: +1-781-472-8103
RTechEmail: arin@constantcontact.com

OrgAbuseHandle: ABUSE1897-ARIN
OrgAbuseName: Constant Contact Abuse
OrgAbusePhone: +1-781-472-8103
OrgAbuseEmail: abuse@constantcontact.com

OrgNOCHandle: CCO156-ARIN
OrgNOCName: Constant Contact Operations
OrgNOCPhone: +1-781-472-8103
OrgNOCEmail: arin@constantcontact.com

OrgTechHandle: CCO156-ARIN
OrgTechName: Constant Contact Operations
OrgTechPhone: +1-781-472-8103
OrgTechEmail: arin@constantcontact.com

Threat Model vs Control Model - Risk Assessments

nospam@example.com (Keith Pachulski) — Sat, 27 Mar 2010 12:28:44 -0400

In recent debate was the applicability of two different types of models used during the course of some risk assessments. These being the Threat^[?] Model, the other being the Control Model.

In the Threat Model, the development of controls is based primarily on the threats identified during the risk assessment process. By threat^[?], I'm referring to the threat source and the typical methods of operations (MO) those threats may pose during their course of operations to leverage specific vulnerabilities which may be in existence on the systems being reviewed. For purpose of this discussion, I'm going to be using Russia, as it exists at this day, and the typical methods being utilized to exploit vulnerabilities against public facing web servers. The threat source, Russia, and the most popular method at this time are PHP Remote include and SQL injection attacks. The important thing to realize immediately is that we have not once mentioned what is in operation on the server. With the threat model, we're not focusing on the vulnerabilities on the server, we are focused on the threat. This model is entirely reactive to the current and trended threats.

The Control Model is based with its focus on the development of controls against potential vulnerabilities discovered during the risk assessment. The Controls being those technical or procedural implementations meant to mitigate a specific issue or issues. With the control model the focus ignores the threats as discussed in the previous model and focuses on the vulnerabilities.

In the Threat Model we notice that Russia has been consistently issuing PHP remote include attacks. As we have identified both the threat source, as well as the potential threat. We can now develop an applicable control to mitigate the specific type of threat. We now either deny the entire Russian AS (autonomous system) block from entering our network or we decide to generate specific Snort rules to re-actively either deny the connections or return false information. We have now either mitigated the threat, to some degree. Bearing in mind of course the threat model is a reactive approach, akin to a cat and mouse game..at least in my humble opinion.

In the Control Model we would not initially acknowledge the threat or the MO. We would have reviewed the server in great detail, hardened it and cataloged its purpose as well as all software in operation on the system and of those softwares, noted which software were available for access to the public and/or internal users. If PHP were installed, it would not expose itself and would not allow for remote includes as part of the hardening process.

Note the major differences, as well as the flaws. The two major schools are of course flawed when used independently. The "perfect" risk assessment would utilize both as part of the general process. Any assessor who does not realize this and certifies the system will unfortunately be spending much time shortly thereafter learning the joys of being part of the incident handling process.

The assessment process must include as part of the initial risk assessment process a review of not only the threats and threat sources and develop one set of controls specifically dealing with those items. After which, additional controls should be developed based on the system security review to include the general configuration of the server, software in operation, the configuration of the software installed, the availability of the software to both the general public as well as the internal user base. After both sets of controls are developed, the two should then be reviewed for overlaps, relevancy as well as the actual ability to implement the controls.

Bearing in mind of course, this is only a small portion of the entire risk assessment process....I'm done with my rant on this topic, for now anyhow =)

Update: Social Mining Tools and Sites

nospam@example.com (Keith Pachulski) — Sat, 13 Mar 2010 12:36:00 -0500

Short list of some interesting sites and tools for performing some simple social mining and information gathering...

Social Engineering Toolkit is a tool based around social engineering that integrates into metasploit. I'll be going into this tool more in later entries.

- SET includes some really useful addons such as generating PDF's with metasploit payloads to "autopwn" your targets..download the most recent via svn and check it out

The following sites are good starting points in developing your target base by searching for the specific person or an organization.

- Addict-o-Matic
- Social Mention
- Entity Cube
- Yasni

Facebook Applications

- Advanced Search 2.0 Beta
- Google Social Search

OpenSolaris 9/6 versus CentOS 5 - Passive Intrusion Detection Sensor

nospam@example.com (Keith Pachulski) — Mon, 21 Dec 2009 20:33:00 -0500

So let me precede this with, I really like both Solaris 10 and OpenSolaris. I like ZFS (mirroring and raidz especially), SMF, containers, the ease of both system and security management etc etc.

My test was to put OpenSolaris 9/6 head to head against CentOS 5 as a passive intrusion detection sensor.

The location in the network for this live experiment was the same, the hardware was the same and the amount of traffic observed by the system with each O/S load was exactly the same.

After a one month period of operation having OpenSolaris and CentOS 5 in operation with only snort and ntop as the major processes, the following behavior was observed:

1) Memory utilization on opensolaris was slightly increased over CentOS 5
2) CPU Utilization on opensolaris was greatly increased over CentOS 5
3) libpcap on opensolaris dropped on average 60% of the traffic under high load conditions where CentOS 5 dropped approximately 40% - neither of those numbers are great