Security Ripcord

Companies are always changing their user agreements and public statements. After reading Jeremiah Grossman’s post on PayPal disclosure statement I got a creepy feeling about actually trusting the statement. I will probably never attempt to test the security of PayPal’s site, but for those who do I would hate for the disclosure statement to change suddenly. So, I have copied the statement, pasted it into a file, and determined the SHA-256 and SHA-512 values. I’m not sure if it is even useful, hopefully nobody ever needs it, but here it is just in case.

[user@localhost Development]$ cat paypal.txt
Reporting site security issues

Our team of dedicated security professionals works vigilantly to keep customer information secure. We recognize the important role that security researchers and our user community play in keeping PayPal and our customers secure. If you discover a site or product vulnerability please notify us using the guidelines below.

To encourage responsible disclosure, we commit that – if we conclude that a disclosure respects and meets all the guidelines outlined below – we will not bring a private action or refer a matter for public inquiry.

Guidelines for responsible disclosure

* Share the security issue with us before making it public on message boards, mailing lists, and other forums.
* Allow us reasonable time to respond to the issue before disclosing it publicly.
* Provide full details of the security issue.

Do not engage in security research that involves

* Potential or actual denial of service of PayPal applications and systems.
* Use of an exploit to view data without authorization, or corruption of data.
* Requests for direct compensation for the reporting of security issues either to PayPal, or through any external marketplace for vulnerabilities, whether black-market or otherwise.

Report security vulnerabilities to sitesecurity@paypal.com.
Our PGP key for reporting can be found here.

Forward spoof and phishing emails to spoof@paypal.com.
[user@localhost Development]$ sha256sum paypal.txt
c42f72aea29f3e558d835b6c5df943498429c3c4a2c81b531e462cea01e48716 paypal.txt
[user@localhost Development]$ sha512sum paypal.txt
b545c30ac6c1531160f19b9c9de0118f80f48fe7ebd0096a6f161ed4ed136d31e528e938b79b19db8a89edb90a8d45018e0d4d8c77b9f61994eada66440f05f8 paypal.txt
[user@localhost Development]$

Go forth and do good things,
Don C. Weber

Paypal, disclosure, assessment, web, Security Ripcord, Jeremiah Grossman

I just added a post to the Security Catalyst site. During the recent podcast (Security Catalyst #27), Michael Santarcangelo wanted to start a forum topic about What Are The First 5 Actions, Security Catalyst Case Study. As I am starting to think about this very subject I am very interested in everybody’s point of view on this. Please comment on my post either at the Security Catalyst site or here. As I state in the forum I have very thick skin and I value your input.

———————————————

Some of these may seem a bit broad but that is how they are intended. That is because I think that these are the basis for a plan. Before you start deploying systems and connecting them to the Internet, or let end-users run around the internal network, you need to cover the basics and create a managed, secure environment. There should also be a sub-step for each of these to review the findings of the previous steps to see if the new information affects them.

1. Incident Response Policy - this is going to happen at some point. It would be tragic if it happened right off the bat but stranger things have happened. You need to identify how this is going to be handled and individual responsibilities.
2. Prioritized Asset Identification - How do you know how to protect something unless you have identified what needs to be protected and which is most important.
3. Acceptable Use Policy - This will help you determine how your external and internal protections will be configured.
4. Network Deployment Review - If they have a network plan figured out but it has not been review by the Security Manager then it is still in development. At the least the network plan needs to be reviewed at this point to ensure that the previous steps have not created changes.
5. Deployment Strategy - Now that you have a list of assets, know what the network will be used for, and understand the network deployment scheme you need to determine how you will deploy and manage your assets. This strategy should cover how systems are built, hardened, managed, updated, and connected to the network.

I have thick skin so please hack away at this. I will be doing this very thing very soon and I hope to use this as a sounding board.

Thank you,
Cutaway

———————————————

Yes, thank you all,

Cutaway

As a part of the SANS Advisory Board I try to respond to questions whenever possible. Recently somebody wrote in about how to secure a workstation designed for auditing. The following was my response.

Securing an auditing workstation is important but you also want to
be sure that you do not limit services that you may need to use during
an audit or penetration test. I usually protect my system with a
host-based firewall and create a backup of the system should I need to
restore it to a known good state (Knoppix style security toolkits make
this easier still). Perhaps the most important thing is to control the
system and limit access to it to specific personnel.

Perhaps you should consider using a laptop for this type of
activity. That way you can control access to the system better and it
will not be constantly connected to your network. Two factor
authentication (fingerprint, smart cards, etc) using included or add-on
hardware is becoming more prevalent and easier to obtain. You might
take this into consideration to protect such a precious and potentially
dangerous system.

You may also have to consider your network configuration when doing
testing. Some traffic may be denied by your network devices. Although
this could stop an attack it does not necessarily mean that your system
or application is secure. You may need to permit unusual traffic to and
from this system so that you can fully test your environment. You
should be very careful making these types of changes and have procedures
and inspections to return the environment to the operation state.

If you still want to lock down the operating system and applications
on this system, I would take a look at the checklists provided on the
S.C.O.R.E site (https://www.sans.org/score/). This site also has links
to the CIS tools and guides mentioned by others.

Hopefully this is helpful to others as well. Another board member also pointed out that he has written an honors paper covering this topic: Auditing a Systems Security Consultant’s Laptop Running Fedora Core 2. Having written a paper for my GNSA-Gold certification and having voted on dozens of GSEC honors papers (under the old honors process) I know that this paper is thought of highly by the GNSA graders. After a quick review I think that it is a very good place to start. Although this paper is written for a laptop system most of the issues it addresses can and should be applied to any auditing system. Just because a system is not portable does not mean it cannot get up and walk away.

A system configured for auditing and penetration testing should be considered a high risk asset and treated as one. The capabilities of this system and the potential information that it contains are underprotected at your own risk. One other consideration should be made about how to restrict and protect information collected by this system and written to media. A perfect example of this is the recent activity at McAfee as outlined in the InfoWorld article Auditor loses thousands of McAfee employees’ data.