Skip navigation
All Places > Products > RSA Archer Suite > Blog > Author: Meel

RSA Archer Suite

2 Posts authored by: Meel Employee

Warren Buffett recently sent out biennial letter to Berkshire Hathaway managers re-emphasizing the top priority “we can afford to lose money – even a lot of money. But we can’t afford to lose reputation – even a shred of reputation”. This is a powerful statement & goes to the heart of managing a business.

105180

Given the security landscape today, reputation is at risk not just from bad governance in the company, but also from how the security is managed so adversaries are kept at bay.

 

Picture this: a global organization, with thousands of employees, billions of dollars in revenue and a stellar reputation. The IT team is tasked to get a good handle on managing the ever growing pile of vulnerabilities. This is a big pile of unknown risk that needs to be addressed.

 

Since the IT team understands the problem well, they decide to create a homegrown solution figuring it will be easy to customize and they can then shape the solution based on the unique business requirements. The team then builds a case for quick return on investment and wins go-ahead.

As the team embarks on this journey, they start to feel some of the challenges. The first step is to nail down the requirements then build the solution. However, the requirements seem to be a never ending stream. As they get close to finishing the solution they get the feeling that building the solution was probably the easy part.

 

This is when they begin to realize that the solution may not be sustainable!

 

Some of the challenges they run into –

  • Full time resources are required to continue to enhance & maintain the solution.
  • The brightest resources are taken away from security tasks and are dedicated to managing the solution.
  • Functionality is limited. As an example, cannot identify unique assets since the algorithm is based off IP addresses as primary keys, which leads to assets with overlapping IP addresses.
  • Can’t get away from using Sharepoint in some form or the other.
  • Reports are still generated manually and not consistent quarter-over-quarter.

 

From a business perspective, what does this lead to?

  • More resources are required for managing vulnerabilities.
  • Lack of resources push some of the required activities such as penetration testing into corner.
  • Unaddressed vulnerabilities are still rising. Rapid remediation validation is not happening leading to closing of vulnerabilities that have not been remediated.
  • Tracking of vulnerability is quite tedious. Business line managers are unable to see where their requests are in review & approval process.
  • The IT team is limited in the metrics & KPIs (key performance indicators) they can create for the vulnerability management process.

 

You can be proactive and avoid these negative business outcomes.

In the end you are looking to guard the reputation of the business. Managing security in the right way can yield a significant competitive advantage by protecting the reputation of business in the long run. Do it the right way.

 

-

Stay in touch @RajMeel7

Shellshock, you have heard about it, have brainstormed with your teams and now must be assessing how much is the impact to your organization or division. Let’s take a look at some of the steps that you can take to understand and enhance your security posture.

 

Starting point: Take inventory. Identify the devices that are potentially most vulnerable. These include that have “bash” installed on them.

If you are using RSA VRM (Vulnerability Risk Management) you can easily run a query rule to search for all scanned devices that have “bash”. All the information about scanned devices is already stored in the warehouse. VRM creates an active catalog of assets that is auto updated & totally in sync with what network vulnerability scanners are seeing in the environment.

 

The security analyst can run a simple query to find all devices that have “bash”. This will provide the starting inventory of devices. Proactively, the analyst can create alerts so he can monitor on his dashboard the current devices with “bash” and any new devices that are added which have “bash”.

96658

Once you have identified which devices have bash installed, as a second step, check for the devices that have sister shells such as “/bin/sh” installed, as sometimes these are copies of bash.

 

This gives a good first pass on the inventory of devices that could be impacted by Shellshock.

 

Now, you also want to cover your bases by looking for all devices that have the known “shellshock” vulnerabilities. The security analyst can run a search query on devices using CVE ids of “shellshock” vulnerabilities. So far, six vulnerabilities have been identified that are related to Shellshock: CVE-2014-6271, CVE-2014-7169, CVE-2014-7186 & CVE-2014-7187 and CVE-2014-6277 & CVE-2014-6278.

Four of these vulnerabilities (CVE-2014-6271, 7169, 6277, 6278) are related. CVE-6271 is the key vulnerability amongst these and the other three exist because of incomplete fixes.

96659

96690

The patches are not available for some of these, yet. So, keeping a close eye on the inventory of devices would be helpful.

 

So far, you have created a good list of devices by searching for specific vulnerabilities as well as shell (bash or sh).

 

Now, prioritize the devices that need to be patched first. You may want to consider prioritizing these devices based on criticality and business context (who owns the device, risk rating, compliance rating).

As an example, E-mail servers are considered to be potential targets for Shellshock, so you may want to include type of device to patch as a key parameter in your prioritization scheme. Once you have a strategy to prioritize then you can easily add new devices such as Network Attached Storage, which has recently been identified as a target of “shellshock” attack.

 

Once prioritization is determined, kick off a remediation work flow. Involve the decision makers and cross-functional teams that are stake holders. This will provide the necessary foundation to establish the vulnerability management program for Shellshock. Follow-thru by iterative improvement in the process as you go along the remediation process.

 

Manage exceptions along the way, so the risk is properly identified and the concerned people are notified to obtain the risk exception approval.

In summary,

  • Take inventory of devices with Shellshock vulnerabilities
  • Prioritize based on criticality and business context
  • Establish vulnerability management process
  • Use KPIs to iteratively improve the vulnerability management process

 

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Here is a quick summary on GNU bash vulnerabilities:

  1. CVE-2014-6271: GNU Bash 4.3 and earlier contains a command injection vulnerability that may allow remote code execution (aka Shellshock/Bashbug). Bash supports exporting of shell functions to other instances of bash using an environment variable. This environment variable is named by the function name and starts with a "() {" as the variable value in the function definition. When Bash reaches the end of the function definition, rather than ending execution it continues to process shell commands written after the end of the function.
  2. CVE-2014-7169: This vulnerability exists because of an incomplete fix for CVE-2014-6271
  3. CVE-2014-7186: The redirection implementation in parse.y in GNU Bash through 4.3 bash43-026 allows remote attackers to cause a denial of service (out-of-bounds array access and application crash) or possibly have unspecified other impact via crafted use of here documents, aka the "redir_stack" issue.
  4. CVE-2014-7187: Off-by-one error in the read_token_word function in parse.y in GNU Bash through 4.3 bash43-026 allows remote attackers to cause a denial of service (out-of-bounds array access and application crash) or possibly have unspecified other impact via deeply nested for loops, aka the "word_lineno" issue.
  5. CVE-2014-6277: This vulnerability exists because of an incomplete fix for CVE-2014-6271 and CVE-2014-7169
  6. CVE-2014-6278: This vulnerability exists because of an incomplete fix for CVE-2014-6271, CVE-2014-7169, and CVE-2014-6277

 

Reach me on Twitter:@RajMeel7 

Filter Blog

By date: By tag: