Information Security, Privacy and Regulatory Compliance

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

Overview

nospam@example.com (Keith Pachulski) — Tue, 10 Aug 2010 13:41:00 -0400

Someone asked me recently, why did I maintain a blog. Well, here is the answer. I have a blog because there are people out there who have questions. Questions that me and others may consider only need to be quick answers. Quick answers are of course misunderstood or forgotten then asked again. So, rather than giving someone a quick verbal answer, which I'll likely do anyhow, I maintain this to answer those technical questions like how does this or that work. I also maintain it because I like a Soapbox to bitch about things in the industry that continue to drive me nuts =) The Wiki/Knowledgebase and Project Tracking are up and are under construction. If you are interested in contributing to the various forums or research, feel free to shoot me an email and create an account on the site. The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way. -Keith

ShoeCon Security Conference

nospam@example.com (Keith Pachulski) — Tue, 10 Aug 2010 13:38:04 -0400

ShoeCon 2010:

Date/Locale:
Atlanta, GA September 18th
Wellesley Inn-Atlanta Airport
1377 Virginia Avenue
East Point, GA 30344
(404) 762-5111

If you are interested in speaking at this Conference then we are interested in talking with you. The September DC404 meeting will also be held at the Con.
This is a donation supported event and all the proceeds will go to the Matthew Shoemaker Memorial Fund.
We also need volunteers, donations of swag, time, etc.

The isdpodcast website has made it easy for you to donate to the Matthew Shoemaker Memorial Fund. Anything you can spare would certainly be appreciated.

Call (404) 890-5379 or email isdpodcast@gmail.com us with your questions or comments.

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...

BART (Basic Audit and Reporting Tool) on Solaris 10/OpenSolaris

nospam@example.com (Keith Pachulski) — Fri, 30 Jul 2010 23:57:08 -0400

As a follow-up to a conversation regarding this; BART is one of those integrated features that is often overlooked in the Solaris 10/OpenSolaris distributions. BART at it's core function similar to other host file integrity check systems. While it is a nice tool for small shops, it is by no means well suited for large scale deployments. For mid to large scale system integrity verification and host level intrusion detection/prevention systems I`m of course still an advocate of OSSEC^[?]. For clarification, BART only performs file integrity checking and does not monitor log files or system processes etc...

Creating the BART Manifest

This would be an example of a simple manifest recording the attributes of all files within the /etc, /boot, /sbin and /usr directories and generate an md5 hash for each file.

bart create -R /etc /boot /sbin /usr > /bart/control

Included in the control file would contain single line entries for each file, link, etc

/X11/fontpath.d/misc:unscaled:pri=15 L 35 120777 - 4c50ebb0 0 0 ../../../usr/X11/lib/X11/fonts/misc
/X11/gdm/Init/Default F 2640 100755 owner@::deny,owner@:read_data/write_data/append_data/write_xattr/execute/write_attributes/write_
acl/write_owner:allow,group@:write_data/append_data:deny,group@:read_data/execute:allow,everyone@:write_data/append_data/write_xattr
/write_attributes/write_acl/write_owner:deny,everyone@:read_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow 4a0c3
e11 0 3 bf7503995330dc79b078bdba2171d657

Each line will contain a notation defining what each entry is, these are as follows:

# Format:
#fname D size mode acl dirmtime uid gid
#fname P size mode acl mtime uid gid
#fname S size mode acl mtime uid gid
#fname F size mode acl mtime uid gid contents
#fname L size mode acl lnmtime uid gid dest
#fname B size mode acl mtime uid gid devnode
#fname C size mode acl mtime uid gid devnode

- B for a block device node
- C for a character device node
- D for a directory
- F for a file
- L for a symbolic link
- P for a pipe
- S for a socket

Further available attributes are as follows:

size - File size in bytes.
mode - Octal number that represents the permissions of the file.
acl - ACL attributes for the file. For a file with ACL attributes, this contains the output from acltotext().
uid - Numerical user ID of the owner of this entry.
gid - Numerical group ID of the owner of this entry.
dirmtime - Last modification time, in seconds, since 00:00:00 UTC, January 1, 1970, for directories.
lnmtime - Last modification time, in seconds, since 00:00:00 UTC, January 1, 1970, for links.
mtime - Last modification time, in seconds, since 00:00:00 UTC January 1, 1970, for files.
contents - Checksum value of the file. This attribute is only specified for regular files. If you turn off context checking, or if checksums cannot be computed, the value of this field is –.
dest - Destination of a symbolic link.
devnode - Value of the device node. This attribute is for character device files and block device files only.

Create the diff manifest and check for changes

To verify BART is functioning correctly, we'll create a test file in the /etc directory

keithp@opensolaris:/bart# touch /etc/thisisatest

Once the test file has been created we now need to run BART again to generate the differential manifest

keithp@opensolaris:/bart# bart create -R /etc /boot /sbin /usr > /bart/control-diff

After the diff manifest has generated, we then verify that any changes that have occurred, as well as checking for the test file being created.

keithp@opensolaris:/bart# bart compare control control-diff > bart-modifications
keithp@opensolaris:/bart# more bart-modifications
/thisisatest:
add

The test file we created was detected. No other modifications were found. The downside to BART is that if any changes were discovered that were legitimate. BART does not automatically update the control file. The control-diff would now become the primary file from which future checks are performed against. To automate the BART checks, add a cronjob to perform the creation of the new differential file as well as performing the compare jobs.

0 7,14,21 bart create -R /etc /boot /sbin /usr > /bart/control-diff
30 7,14,21 bart compare control control-diff > bart-modifications

Centralized BART Monitoring

With some creativity, through the NFS/automount, you can create a hub and spoke type design where the spoke systems individually create the control and diff files. The control files can be moved to the central server and the diff files remain on the spoke systems. Additional cronjobs would be created that would compare the manifest on the central server to the diff manifest located on the spoke systems. Bearing in mind of course that NFS is not encrypted by default but with some simple tweaks you can implement service level encryption to secure the NFS traffic between the central and spoke systems. But again, why recreate the wheel?

Again, it's nice to tinker with or act as a second line of auditing. But I would strongly urge a system like OSSEC be implemented to perform the centralized monitoring and reporting.

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..

Nikto with NMAP for Web Server Scanning

nospam@example.com (Keith Pachulski) — Sun, 20 Jun 2010 16:15:00 -0400

Nikto is a lightweight, portable, PERL based web application scanner. The only requirements for Nikto to run are PERL and NET SSLeay, NET SSLeay is only needed if you plan on auditing SSL based applications. Nikto requires you to input the targets from the command line, because of this we’ll also be using NMAP with the http-headers NSE scripts to identify and gather basic information on HTTP based services for this overview. Nikto, as a standalone package, does not include the ability to perform port/service scanning. As such, NMAP will additionally need to be installed on the system performing the audits. NMAP is not a requirement; it just makes things easier…

Required Software/Packages:

Nikto

http://cirt.net/nikto2

Net SSLeay

http://search.cpan.org/CPAN/authors/id/S/SA/SAMPO/Net_SSLeay.pm-1.25.tar.gz

NMAP

http://www.nmap.org/download

NMAP HTTP-Headers NSE

http://nmap.org/svn/scripts/http-headers.nse

NMAP with NSE to discover potential Web Applications

This section assumes you are running at minimum nmap 5.21, nmap 5.2x is required for the application awareness checking of nmap. To begin, we will be probing the targets systems to discover all services and identify what is running on them using the service aware nmap config, but also using the http-headers nse to gather interesting information about the system(s) with potential web applications. From the nmap output, we’ll be targeting those systems running some type of web application. Side Note: for those services that show up as unknown, be sure to manually probe them later. nmap --script http-headers.nse -p 1-65535 –A

I’m targeting all ports here via nmap as some people still believe security through obscurity is a valid mechanism, don’t overlook anything. There are several other options for service level probing you may want to investigate, but for this I’m doing the quick and dirty.

Once nmap has completed its run, it will spit out everything it found to the console, from that list we will target the services to be audited with Nikto.

$ nmap --script http-headers.nse 192.168.0.1 -A

Starting Nmap 5.21 ( http://nmap.org )
NSE: Script Scanning completed.
Nmap scan report for 192.168.0.1
Host is up (0.0012s latency).
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.2.3 ((CentOS) mod_python/3.2.8 Python/2.4.3 mod_ssl/2.2.3 OpenSSL/0.9.8e-fips-rhel5 mod_perl/2.0.4 Perl/v5.8.8)
443/tcp open ssl/http Apache httpd 2.2.3 ((CentOS) mod_python/3.2.8 Python/2.4.3 mod_ssl/2.2.3 OpenSSL/0.9.8e-fips-rhel5 mod_perl/2.0.4 Perl/v5.8.8)

Installing Nikto and targeting the discovered web applications

Obtain the Nikto package and the NET SSLeay packages from the following locations:

Install NET SSLeay then untar the nikto package to your home directory, update Nikto

./nikto.pl –update

From the nessus NSE scan above, we found the following services in operation that are of interest:

80/tcp open http Apache httpd 2.2.3
5801/tcp open vnc-http RealVNC 4.0
3000/tcp open http WEBrick httpd 1.3.1
443/tcp open ssl/http Apache httpd 2.2.3

At the command line, we target these web applications specifically with Nikto by using the following type of command:

./nikto –h 'target' -p 80,443,5801,3000 –ssl –output report.html

As Nikto is performing the targeted assessment, any potential issues will be displayed to the console. As the scan is occuring, all results are output to the html file with the details of the scan along with the corresponding OSVDB^[?] identifiers broken down by service port tested.

The export format may additionally be set to either csv or XML as needed: report.csv, report.xml

Executing nmap and passing the results directly to nikto

This is useful when you want/need to check all active web servers in the target subnet(s). The following executes the nmap scan of the target subnet then pipes the discovered hosts to nikto.

nmap 192.168.0.0/24 -oG - | ./nikto.pl -output subnet.html -h -

Closing

Nikto standalone, I wasn't overly thrilled with. But again, in a pinch it is a nice tool to keep in the box. In testing nikto, some scans were needed to be run several times for nikto to actually do what it had been configured to do via the command line. The reporting isn't that clean, still leaves a lot of room for interpretation and understanding of common issues.

Whole Disk Encryption (WDE) – And Comparison of PGP vs TrueCrypt for WDE

nospam@example.com (Keith Pachulski) — Thu, 03 Jun 2010 20:40:37 -0400

Whole Disk Encryption (WDE^[?]) – And Comparison of PGP vs TrueCrypt for WDE

In this day and age there is absolutely no reason for any business with laptops being used for business or personal reasons that contain sensitive information to not be encrypted.

Whole Disk Encryption, also known as Full Disk Encryption, is what it says; it encrypts all information contained on the specified disk or partition. WDE should not however not to be confused with file system encryption. With WDE one key is used to encrypt the entire disk. Should the key become compromised, the entire disk is thereby compromised. For those individuals needing or who are required to transmit sensitive information on their laptops, I would strongly recommend using WDE in conjunction with file system encryption.

File system encryption is often known as folder or file encryption because it was designed, from a high level, to encrypt specific targets within the system whereas WDE deals with the entire disk.

File System encryption examples can be found in a previous blog post on TrueCrypt Containers for examples.

TrueCrypt vs PGP	TrueCrypt	PGP
Cost	Free	$149.00
Encrypt internal, external and removable media	yes	yes
Encrypt all user data, applications, boot sector and swap files	yes	yes
Shred/Wipe Function	no	yes
Encrypt Email	no	option $$
Encrypt IM	no	option $$

TrueCrypt Whole Disk Encryption on Windows - Step by Step

Select Create Volume

Encrypt the system partition or entire system drive

Type of System Encryption - Normal

Area to Encrypt – Encrypt the whole drive

Encryption of the Host Protected Area – If you know there are utilities in the Host Protected Area (HPA) you do not want encrypted, select No – Otherwise encrypted the HPA as well

Number of Operating Systems – Select the appropriate response, typically this will be 1

Encryption Options – Select the Preferred Encryption and hashing Algorithms – for NIST^[?] compliance select AES^[?]

Notes:
Unlike PGP below where you generate your public/private keypair that can be used for other PGP plug-in applications, the keys for TrueCrypt are generated based on the movement of your mouse and are only used for drive encrypt/decrypt functions
If you are overly paranoid, you can select a cascading algorithm here such as AES+TwoFish to increase the strength

Password – enter the password, this will be used to access the system once the entire disk has been encrypted

Rescue Disk – The iso image created must be copied off the system and it is recommended it be burnt to a CD. This will be required if the password is forgotten or any portion of the loader becomes corrupted. Once the image has been burnt, eject and reinsert the CD and click next to allow Truecrypt to verify the image. Once it has completed, it will ask you to reboot, select yes for the encryption Pretest.

At the boot prompt, enter the password you had entered earlier.

Once Windows boots, you'll be presented with the Pretest screen and the option to begin the encryption process, select Encrypt, go for a coke...

The encryption status window will appear, once the disk encryption has completed a notification window will appear.

That’s about all that you need to do.

If for whatever reason you want to permanently decrypt the drive, open the TrueCrypt application, select System then “Permanently decrypt system partition/drive”.

PGP (Pretty Good Privacy) WDE on Windows - Quasi Step by Step

The setup is pretty straightforward and almost identical to the TrueCrypt setup; install the application from the exe. Once it finished open the PGP Desktop application from the system tray and click on PGP Disk then Encrypt Whole Disk.

During the installation you`ll be prompted to create a key pair. These keys will be used for encrypting and decrypting the drive(s). These are also the keys you`ll use if you buy the extra PGP addons such as email. Make sure you use your legitimate email address during creation.

It is recommended you create a recovery disk, same as a above.

Select the disk to encrypt then select the keys you created during installation by selecting Add User Key.

Click Encrypt, go for a coke..

By default PGP uses AES-256 for encryption and SHA-1 for hashing. As far as I am aware there is no possible customization to either the encryption or hashing algorithms.

Soap Box

While I am a huge fan of TrueCrypt for only WDE or file system encryption, it does not scale well in large deployments like PGP offers with the Universal Server. With the PGP Universal Server, enrollments and encryption policies can be controlled and deployed from a central server. The PGP server can generate "reports" from the server on demand. I put the quotes around the word report because the export is simply a csv export of the entire database structure, which is severely lacking in the ability to perform decent reporting and database maintenance.

Seriously though, with whatever solution you choose..choose one. The 30 minutes of your time it takes to install and configure the software will pale in comparison to being immortalized on the Internet as yet another failure to protect sensitive information...

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