Showing posts with label Risk. Show all posts
Showing posts with label Risk. Show all posts

Sunday, May 31, 2009

Cyberspace Security Review

On Friday (May 29, 2009) President Obama announced the nation’s plan to defend against attacks on the nation's computer networks; a “strategic national asset.” This plan includes appointing a Cyber-Security Chief, whom he has not yet chosen, in the White House. Obama will sign a classified order within the coming weeks that will create the military cybercommand.

He stated that cyber-criminals have cost US citizens over $8 billion worth of stolen data and that the figure worldwide was up to $1 trillion.

The announcement came with the release of the Cyberspace Security Review, a 76 page document that had 60-days to be completed from the date of the initial request. The Cyberspace Security Review explains how the US intends to secure its critical network infrastructure. It was stated that the review was necessary because, “America's failure to protect cyberspace is one of the most urgent national security problems facing the new administration”, and that, “our digital infrastructure has already suffered intrusions that have allowed criminals to steal hundreds of millions of dollars and nation-states and other entities to steal intellectual property and sensitive military information.”

The Cyberspace Security Review made the following 10 recommendations for near-term action:

  1. Appoint a cybersecurity policy official responsible for coordinating the Nation’s cybersecurity policies and activities; establish a strong NSC directorate, under the direction of the cybersecurity policy official dual-hatted to the NSC and the NEC, to coordinate interagency development of cybersecurity-related strategy and policy.
  2. Prepare for the President’s approval an updated national strategy to secure the information and communications infrastructure. This strategy should include continued evaluation of CNCI activities and, where appropriate, build on its successes.
  3. Designate cybersecurity as one of the President’s key management priorities and establish performance metrics.
  4. Designate a privacy and civil liberties official to the NSC cybersecurity directorate.
  5. Convene appropriate interagency mechanisms to conduct interagency-cleared legal analyses of priority cybersecurity-related issues identified during the policy-development process and formulate coherent unified policy guidance that clarifies roles, responsibilities, and the application of agency authorities for cybersecurity-related activities across the Federal government.
  6. Initiate a national public awareness and education campaign to promote cybersecurity.
  7. Develop U.S. Government positions for an international cybersecurity policy framework and strengthen our international partnerships to create initiatives that address the full range of activities, policies, and opportunities associated with cybersecurity.
  8. Prepare a cybersecurity incident response plan; initiate a dialog to enhance public-private partnerships with an eye toward streamlining, aligning, and providing resources to optimize their contribution and engagement.
  9. In collaboration with other EOP entities, develop a framework for research and development strategies that focus on game-changing technologies that have the potential to enhance the security, reliability, resilience, and trustworthiness of digital infrastructure; provide the research community access to event data to facilitate developing tools, testing theories, and identifying workable solutions.
  10. Build a cybersecurity-based identity management vision and strategy that addresses privacy and civil liberties interests, leveraging privacy-enhancing technologies for the Nation.

What is promising about the Review is that there's repeated focus on outcomes as opposed to the inputs. Too often forward progress is hindered by the inefficient efforts of trying to define process before goals and objectives are clearly defined and understood. Rather, the Review consistently attempts to make it clear what the strategic outcomes are, and from those objectives, the development of process will be guided.

The Review also states, “Other structures will be needed to help ensure that civil liberties and privacy rights are protected.” The inclusion to help protect our privacy and civil liberties is an indication of the balanced intention of the plan.

Money will also be set aside for research and development of security technologies, from which there will be significant opportunity.

What I'm not certain about is the overall effectiveness the Cyber-Security Chief will have. Specifically, the position will not have direct access to the president. As a result, this position may not be high-level enough to prevent the almost certain bureaucratic nonsense, internal bickering and games that could waste millions/billions of dollars.

Though the Review solely focusses on defensive measures, I'm also curious what efforts are underway, if any, towards the development and potential use of cyberweapons.

Overall, the document doesn't suggest that there will be any major changes that will affect the private sector within the near term. The Review recommends specific changes to the direction of future US policies. Within the mid-term I imagine that lawmakers will develop regulations that will require the sharing of security incident data from the private sector with the government, presumably tempered with the commitment to ensure civil liberties. I anticipate that we will also see more emphasis put towards penetration testing and incident response.

Steve

###

Wednesday, March 18, 2009

PCI Compliance - Disable SSLv2 and Weak Ciphers

According to section 4.1 of the the Payment Card Industry Data Security Standard (PCI-DSS) v1.2, merchants handling credit card data are required to “use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks.”

What does this mean? In order to validate your PCI DSS compliance in this area you will need to ensure that your relevant server(s) within your PCI environment are configured to disallow Secure Sockets Layer (SSL) version 2 as well as "weak" cryptography. You are also required to have quarterly PCI security vulnerability scans conducted against your externally facing PCI systems. Without disabling SSLv2 and weak ciphers you are almost guaranteed to fail the scans. In turn this will lead to falling out of compliance along with the associated risks and consequences.

The SSLv2 Conundrum

Does your server support SSLv2?

How to test:

You will need to have OpenSSL installed on the system that you will perform the tests from. Once installed, use the following command to test your web server, assuming port 443 is where you're providing https connections:

# openssl s_client -ssl2 -connect SERVERNAME:443

If the server does not support SSLv2 you should receive an error similar to the following:

# openssl s_client -ssl2 -connect SERVERNAME:443

CONNECTED(00000003)

458:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428:

How to configure Apache v2 to not accept SSLv2 connections:

You will need to modify the SSLCipherSuite directive in the httpd.conf or ssl.conf file.

An example would be editing the following lines to look similar to:

SSLProtocol -ALL +SSLv3 +TLSv1

Restart the Apache process and ensure that the server is functional. Also retest using OpenSSL to confirm that SSLv2 is no longer accepted.

How to configure Microsoft IIS to not accept SSLv2 connections:

You will need to modify the system’s registry.

Merge the following keys to the Windows registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]

"Enabled"=dword:00000000

Restart the system and ensure that the server is functional. Also retest using OpenSSL to confirm that SSLv2 is no longer accepted.

Those Pesky Weak SSL Ciphers

Does your server support weak SSL ciphers?

How to test:

You will need to have OpenSSL installed on the system that you will perform the tests from. Once installed, use the following command to test your web server, assuming port 443 is where you're providing https connections:

# openssl s_client -connect SERVERNAME:443 -cipher LOW:EXP

If the server does not support weak ciphers you should receive an error similar to the following:

# openssl s_client -connect SERVERNAME:443 -cipher LOW:EXP

CONNECTED(00000003)

461:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226:

How to configure Apache v2 to not accept weak SSL ciphers:

You will need to modify the SSLCipherSuite directive in the httpd.conf or ssl.conf file.

An example would be editing the following lines to look similar to:

SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM

Restart the Apache process and ensure that the server is functional. Also retest using OpenSSL to confirm that weak SSL ciphers are no longer accepted.


How to configure Microsoft IIS to not accept weak SSL ciphers:

You will need to modify the system’s registry.

Merge the following keys to the Windows registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128]

"Enabled"=dword:0000000

Restart the system and ensure that the server is functional. Also retest using OpenSSL to confirm that weak SSL ciphers are no longer accepted..

At this point have your Approved Scanning Vendor (ASV) scan your external facing PCI environment to validate. Making the above changes should cause the ASV scans to not tag and fail you on the following vulnerabilities:

  • SSL Server Supports Weak Encryption
  • SSL Server Allows Cleartext Encryption
  • SSL Server May Be Forced to Use Weak Encryption
  • SSL Server Allows Anonymous Authentication

Steve

###

Thursday, July 3, 2008

Security: Instant Messaging and Enabling Business

I recently had a colleague ask me about the inherent risks in using Instant Messaging (IM) for business. Certainly, IM is an extremely effective way to communicate with team members and customers who may not be in close physical proximity. However, if used incorrectly, negative impact to the business can be massive.

There's consumer grade and business grade IM solutions. Services such as Yahoo IM are considered consumer grade. All text based IMs can either be routed through a core set of central servers and then on to the recipient, or through peer-to-peer connections. When you combine consumer grade IM services with traffic flowing in the clear (i.e., unencrypted) through central servers outside of the organization's control, you end up with a significantly elevated set of risks. Are these risks worth accepting?

Here are some of the more obvious risks that I see with using consumer grade IM for business:

  • Vulnerable Clients -- advisories for vulnerabilities in chat clients are announced fairly often. Many of these vulnerabilities allow for the remote execution of code on the vulnerable client system
  • Traffic can be viewed ("sniffed") -- by default, consumer grade IM clients send all of their traffic in the clear. There are plugins to provide encryption for some clients, however, all parties involved in the chat will need the crypto plugin enabled and configured correctly
  • Data theft -- a nefarious employee could potentially move critical/restricted data to a location offsite
  • Identity Theft -- The mechanism for consumer grade IM user authentication is weak. Grab the weak authentication traffic and an attacker now has valid login credentials. The stolen credentials can then be used to impersonate the victim and be used as a launch pad to further identify theft
  • Provides IP info to attackers -- if an employee decides to go to an external chatroom with their IM client, their IP is now known to anyone else in the chatroom who may be interested...including a potential attacker. With the IP the attacker can focus their attack to a specific system
  • Privacy...or lack thereof -- see all points above
  • Social Engineering -- more likely to happen if an employee engages in conversations in non-business specific chatrooms
Another risk is in employees using IM for business on their home computers. Imagine, for just a moment, that an employee commits a crime against the business from their home and used IM to enable them to commit the crime. Your business won't have the authority or right to confiscate their home computer for investigation - your hands are tied behind your back. I'm sure you can start seeing where the dangers and risks start to go up.

Additionally, many chat clients will log all conversations to disk. What if confidential or restricted data is logged and stored on an individuals home computer? Other family members, or friends, may have access to that system, or perhaps the home computer is already compromised and under someone else's control (think botnet). Now the attacker can pull the chat logs and have unauthorized access to confidential or restricted data. The impact could be titanic to the business! Of course, confidential or restricted data should never be sent over IM in the first place.

In addition to having policies, procedures, and perhaps even guidelines on the proper use of IM for business, I believe the return on investment by providing an internal and redundant IM service to enable business is compelling and certainly worth considering strategically.

Steve Zenone
###