Risk Management

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

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.

The use of USB devices to introduce malware is by no means a new concept. As technology of course changes, the USB device as a delivery mechanism for malicious content has evolved significantly. The latest release of a USB malware delivery platform is bringing an auto-detecting application that executes the moment the USB drive is mounted by the operating system. The moment the mount is complete, the malware determines the type of operating system and executes it's payload based on the detected operating system whether it be Linux, Solaris, windows, OS X 10 or BSD.

Immediately upon determining the operating system, it executes a memory resident, non-persistant, reverse tcp shell connection or reverse VNC connection from the victim computer to a remote system.

The reverse VNC connection pushes the desktop of the affected user to the attacker allowing him to view or take control of the end users system.

The reverse tcp shell pushes either a Windows command prompt or a Unix shell from the affected system to the attacker. Once the attacker has shell access, the attacker can then depending on the payload use the compromised system as a hinge or swivel to other internal systems (I'll be covering hinge and swivel in another post soon).

During some initial testing of the USB software, the only evidence of malicious activity is apparent on Windows systems where a cmd.exe window will appear very briefly then close. The cmd.exe window is only visible for less than a second, so most end users may not even notice it occur.

What can be done to prevent this type of activity from affecting your business environment or home computers you may be asking?

From the desktop perspective on Windows, enable the Windows Firewall and verify User Account Control (UAC) is enabled. This will stop the payload from first executing through UAC, as long as the person at the keyboard doesn't just click yes to everything that is. The firewall, if configured correctly, is application based by default so will not allow the payload to connect to the destination system.

On *nix based systems though this is a tad more difficult. If the system is a workstation and has iptables/ipf or some other variant enabled, the default ruleset may allow for all outbound connections. Workstations and servers using iptables/ipf should be reconfigured to only allow needed traffic to exit the system. Unfortunately iptables/ipf is not application based, but protocol based so it will require some technical understanding of firewall rules and IP Protocols. This is beyond the scope of this document...maybe I'll write-up an introductory to iptables at a later date...

Signature based Network Intrusion Detection Systems should able to detect the outbound reverse shell. I know Snort has signatures in the default set to detect some of this activity. Host Based Intrusion Detection Systems, if configured to monitor for new processes or processes in operation that are not linked to a binary, will detect this type of payload as well. OSSEC, by default, has this functionality built into it.

Any questions, feel free to ping me...

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 =)