Los RFC (Request For Comments)(Petición de Comentarios) son una serie de documentos cuyo contenido es una propuesta oficial para un nuevo protocolo de la red o línea guía de desarrollo de un proceso, que explica con todo detalle para que en caso de ser aceptado pueda ser implementado sin ambiguedades.
De esta manera la Guía RFC 3227 presenta un línea a seguir para los procesos de recolección y archivo de evidencias digitales en casos de análisis forense digital. Ofrece entonces una serie de mejores prácticas que permiten determinar el nivel de volatilidad de los datos, información a recolectar, almacenamiento y cadena de custodia. Para que estos puedan ser incluidos en procedimiento legales.
Veamos:
Network Working Group D. Brezinski
Request for Comments: 3227 In-Q-Tel
BCP: 55 T. Killalea
Category: Best Current Practice  neart.org
February 2002
Guidelines for Evidence Collection and Archiving
Status of this Memo
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for   improvements.  Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract
A “security incident” as defined in the “Internet Security Glossary”, RFC 2828, is a security-relevant system event in which the system’s security policy is disobeyed or otherwise breached.  The purpose of   this document is to provide System Administrators with guidelines on   the collection and archiving of evidence relevant to such a security   incident.
If evidence collection is done correctly, it is much more useful in  apprehending the attacker, and stands a much greater chance of being  admissible in the event of a prosecution.
Table of Contents
1 Introduction
1.1 Conventions Used in this Document
2 Guiding Principles during Evidence Collection
2.1 Order of Volatility
2.2 Things to avoid
2.3 Privacy Considerations
2.4 Legal Considerations
3 The Collection Procedure
3.1 Transparency
3.2 Collection Steps
4 The Archiving Procedure
4.1 Chain of Custody
4.2 The Archive
5 Tools you’ll need
6 References
7 Acknowledgements
8 Security Considerations
9 Authors’ Addresses
10 Full Copyright Statement
1 Introduction
A “security incident” as defined in [RFC2828] is a security-relevant  system event in which the system’s security policy is disobeyed or otherwise breached.  The purpose of this document is to provide System Administrators with guidelines on the collection and archiving of evidence relevant to such a security incident.  It’s not our intention to insist that all System Administrators rigidly follow these guidelines every time they have a security incident.  Rather, we want to provide guidance on what they should do if they elect to   collect and protect information relating to an intrusion.
Such collection represents a considerable effort on the part of the System Administrator.  Great progress has been made in recent  years  to speed up the re-installation of the Operating System and to facilitate the reversion of a system to a ‘known’ state, thus making the ‘easy option’ even more attractive.  Meanwhile little has been done to provide easy ways of archiving evidence (the difficult   option).  Further, increasing disk and memory capacities and the more widespread use of stealth and cover-your-tracks tactics by  attackers have exacerbated the problem.
If evidence collection is done correctly, it is much more useful in apprehending the attacker, and stands a much greater chance of being admissible in the event of a prosecution.
You should use these guidelines as a basis for formulating your site’s evidence collection procedures, and should incorporate your site’s procedures into your Incident Handling documentation.  The guidelines in this document may not be appropriate under all jurisdictions.  Once you’ve formulated your site’s evidence collection procedures, you should have law enforcement for your jurisdiction confirm that they’re adequate.
1.1  Conventions Used in this Document
The key words “REQUIRED”, “MUST”, “MUST NOT”, “SHOULD”, “SHOULD NOT”, and “MAY” in this document are to be interpreted as  described in “Key words for use in RFCs to Indicate Requirement Levels” [RFC2119].
2  Guiding Principles during Evidence Collection
  • Adhere to your site’s Security Policy and engage the appropriate Incident Handling and Law Enforcement personnel.
  • Capture as accurate a picture of the system as possible.
  • Keep detailed notes.  These should include dates and times.  If possible generate an automatic transcript.  (e.g., On Unix systems the ‘script’ program can be used, however the output file it generates should not be to media that is part of the evidence).  Notes and print-outs should be signed and dated.
  • Note the difference between the system clock and UTC.  For each timestamp provided, indicate whether UTC or local time is used.
  • Be prepared to testify (perhaps years later) outlining all actions you took and at what times.  Detailed notes will be vital.
  • Minimise changes to the data as you are collecting it.  This is not limited to content changes; you should avoid updating file or directory access times.
  • Remove external avenues for change.
  • When confronted with a choice between collection and analysis you should do collection first and analysis later.
  • Though it hardly needs stating, your procedures should be implementable.  As with any aspect of an incident response policy, procedures should be tested to ensure feasibility, particularly in a crisis.  If possible procedures should be automated for reasons of speed and accuracy.  Be methodical.
  • For each device, a methodical approach should be adopted which follows the guidelines laid down in your collection procedure.
Speed will often be critical so where there are a number of devices requiring examination it may be appropriate to spread the work among your team to collect the evidence in parallel. However on a single given system collection should be done step by step.
  • Proceed from the volatile to the less volatile (see the Order of Volatility below).
  • You should make a bit-level copy of the system’s media.  If you wish to do forensics analysis you should make a bit-level copy of your evidence copy for that purpose, as your analysis will almost certainly alter file access times.  Avoid doing forensics on the evidence copy.
2.1 Order of Volatility
When collecting evidence you should proceed from the volatile to the less volatile.  Here is an example order of volatility for a typical system.
  • Registers, cache
  • Routing table, arp cache, process table, kernel statistics, memory
  • Temporary file systems
  • Disk
  • Remote logging and monitoring data that is relevant to the system in question
  • Physical configuration, network topology
  • Archival media
2.2 Things to avoid
It’s all too easy to destroy evidence, however inadvertently.
  • Don’t shutdown until you’ve completed evidence collection. Much evidence may be lost and the attacker may have altered the startup/shutdown scripts/services to destroy evidence.
  • Don’t trust the programs on the system.  Run your evidence gathering programs from appropriately protected media (see below).
  • Don’t run programs that modify the access time of all files on the system (e.g., ‘tar’ or ‘xcopy’).
  • When removing external avenues for change note that simply disconnecting or filtering from the network may trigger “deadman switches” that detect when they’re off the net and wipe evidence.
2.3 Privacy Considerations
  • Respect the privacy rules and guidelines of your company and your legal jurisdiction.  In particular, make sure no information collected along with the evidence you are searching for is available to anyone who would not normally have access to this information.  This includes access to log files (which may reveal patterns of user behaviour) as well as personal data files.
  • Do not intrude on people’s privacy without strong justification.  In particular, do not collect information from areas you do not normally have reason to access (such as personal file stores) unless you have sufficient indication that there is a real incident.
  • Make sure you have the backing of your company’s established procedures in taking the steps you do to collect evidence of an incident.
2.4 Legal Considerations
Computer evidence needs to be
  • Admissible: It must conform to certain legal rules before it can be put before a court.
  • Authentic: It must be possible to positively tie evidentiary material to the incident.
  • Complete: It must tell the whole story and not just a particular perspective.
  • Reliable: There must be nothing about how the evidence was collected and subsequently handled that casts doubt about its authenticity and veracity.
  • Believable: It must be readily believable and understandable by a court.
3 The Collection Procedure
Your collection procedures should be as detailed as possible.  As is the case with your overall Incident Handling procedures, they  should be unambiguous, and should minimise the amount of decision-making needed during the collection process.
3.1 Transparency
The methods used to collect evidence should be transparent and reproducible.  You should be prepared to reproduce precisely the methods you used, and have those methods tested by independent experts.
3.2 Collection Steps
  • Where is the evidence?  List what systems were involved in the incident and from which evidence will be collected.
  • Establish what is likely to be relevant and admissible.  When in doubt err on the side of collecting too much rather than not enough.
  • For each system, obtain the relevant order of volatility.
  • Remove external avenues for change.
  • Following the order of volatility, collect the evidence with tools as discussed in Section 5.
  • Record the extent of the system’s clock drift.
  • Question what else may be evidence as you work through the collection steps.
  • Document each step.
  • Don’t forget the people involved.  Make notes of who was there and what were they doing, what they observed and how they reacted.
Where feasible you should consider generating checksums and cryptographically signing the collected evidence, as this may make it easier to preserve a strong chain of evidence.  In doing so you must not alter the evidence.
4 The Archiving Procedure
Evidence must be strictly secured.  In addition, the Chain of Custody needs to be clearly documented.
4.1 Chain of Custody
You should be able to clearly describe how the evidence was found, how it was handled and everything that happened to it.
The following need to be documented
  • Where, when, and by whom was the evidence discovered and collected.
  • Where, when and by whom was the evidence handled or examined.
  • Who had custody of the evidence, during what period.  How was it stored.
  • When the evidence changed custody, when and how did the transfer occur (include shipping numbers, etc.).
4.2 Where and how to Archive
If possible commonly used media (rather than some obscure storage media) should be used for archiving.
Access to evidence should be extremely restricted, and should be clearly documented.  It should be possible to detect unauthorised access.
5 Tools you’ll need
You should have the programs you need to do evidence collection and forensics on read-only media (e.g., a CD).  You should have  prepared such a set of tools for each of the Operating Systems that you manage in advance of having to use it.
Your set of tools should include the following:
  • A program for examining processes (e.g., ‘ps’).
  • Programs for examining system state (e.g., ‘showrev’, ‘ifconfig’, ‘netstat’, ‘arp’).
  • A program for doing bit-to-bit copies (e.g., ‘dd’, ‘SafeBack’).
  • Programs for generating checksums and signatures (e.g., ‘sha1sum’, a checksum-enabled ‘dd’, ‘SafeBack’, ‘pgp’).
  • Programs for generating core images and for examining them (e.g., ‘gcore’, ‘gdb’).
  • Scripts to automate evidence collection (e.g., The Coroner’s Toolkit [FAR1999]).
The programs in your set of tools should be statically linked, and should not require the use of any libraries other than those on the read-only media.  Even then, since modern rootkits may be installed through loadable kernel modules, you should consider that  your tools might not be giving you a full picture of the system.
You should be prepared to testify to the authenticity and reliability of the tools that you use.
6 References
[FAR1999]   Farmer, D., and W Venema, “Computer Forensics Analysis Class Handouts”, http://www.fish.com/forensics/
[RFC2119]   Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC2196]   Fraser, B., “Site Security Handbook”, FYI 8, RFC 2196, September 1997.
[RFC2350]   Brownlee, N. and  E. Guttman, “Expectations for Computer Security Incident Response”, FYI 8, RFC 2350, June 1998.
[RFC2828]   Shirey, R., “Internet Security Glossary”, FYI 36, RFC 2828, May 2000.
7 Acknowledgements
We gratefully acknowledge the constructive comments received from Harald Alvestrand, Byron Collie, Barbara Y. Fraser, Gordon Lennox, Andrew Rees, Steve Romig and Floyd Short.
8 Security Considerations
This entire document discuses security issues.
9 Authors’ Addresses
Dominique Brezinski In-Q-Tel
1000 Wilson Blvd., Ste. 2900
Arlington, VA 22209 USA
EMail: [email protected]
Tom Killalea Lisi/n na Bro/n
Be/al A/tha na Muice Co. Mhaigh Eo
IRELAND
Phone: +1 206 266-2196
EMail: [email protected]
10.  Full Copyright Statement
Copyright (C) The Internet Society (2002).  All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise  explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction  of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.  However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case  the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO  ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED  WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.

Metodología: NIST SP 800-115

Posted by 4v4t4r On noviembre - 7 - 2009

NIST (National Institute of Standards and Technology) Special Publication 800-42 es una línea guía de recomendaciones en pruebas (Testing) de la seguridad de la  información.

Entre su contenido se destaca lo siguiente:

  • System Development Life Cycle
  • Documenting Security Testing Results
  • Senior IT Management/Chief Information Officer
  • System and Network Administrators
  • Roles and Responsibilities for Testing
  • Network Scanning
  • Vulnerability Scanning
  • Password Cracking
  • Log Reviews
  • File Integrity Checkers
  • Virus Detectors
  • Wireless LAN Testing
  • Penetration Testing

Más información sobre la metodología NIST SP 800-115>>

Descargar Metodología NIST SP 800-115 >>

Penetration Testing Framework

Posted by 4v4t4r On noviembre - 7 - 2009

Penetration Testing Framework es un entorno para la realización de Test de Penetración. En este se describen/definen las etapas involucradas en un Pen-Test y una recopilación de herramientas necesarias para el cumplimiento del mismo.

Entre las etapas podemos encontrar las siguientes:

  • Network Footprinting (Reconnaissance)
  • Authoratitive Bodies
  • Internet Search
  • Metadata Search
  • Social/ Business Networks
  • DNS Record Retrieval from publically available servers
  • Social Engineering
  • Dumpster Diving
  • Web Site copy
  • Discovery & Probing
  • Default Port Lists
  • Enumeration tools and techniques
  • Active Hosts
  • Service Probing
  • Banner Grabbing
  • ICMP Responses
  • Source Port Scans
  • Firewall Assessment
  • Enumeration
  • Fingerprint server/ service
  • DNS Enumeration
  • Web Directory enumeration
  • Vulnerability Assessment
  • Method Testing
  • Vulnerability Scanners
  • Examine configuration files
  • Exploit Frameworks
  • Privilege Escalation
  • Current Level of access
  • Access passwords
  • SQL injection
  • Password cracking
  • Bluetooth Specific Testing
  • Penetration
  • Wireless Penetration
  • Physical Security

Entre las herramientas a utilizar:

  • Netcraft
  • Robtex
  • Maltego
  • Sam Spade
  • Google
  • FOCA
  • VMWare
  • Httcrack
  • Nmap
  • Netcat
  • Amap
  • Xprobe2
  • Hping
  • Unicornscan
  • Fping
  • Firewalk
  • Scanssh
  • Hydra
  • Brutus
  • Firecat
  • Httprint
  • Nikto
  • Dirbuster
  • Cadaver
  • W3AF
  • GrendelScan
  • JoomlaScan
  • Paros
  • WebScarab
  • Cain & Abel
  • LDAP_Brute.pl
  • Repscan
  • TSGrinder
  • VNCrack
  • Ophcrack
  • Medusa
  • SARA
  • Nessus
  • Xscan
  • Metasploit

Más información / Página Oficial de Penetration Testing Framework >>

Descargar Penetration Testing Framework >>

ISSAF – Information System Security Assessment Framework

Posted by 4v4t4r On octubre - 23 - 2009

El Marco de Evaluación de Seguridad de Sistemas de Información es una metodología estructurada de análisis de seguridad en varios dominios y detalles específicos de test o pruebas para cada uno de estos. Su objetivo es proporcionar procedimientos muy detallados para el testing de sistemas de información que reflejan situaciones reales.

ISSAF es utilizado en su mayoría para cumplir con los requisitos de  evaluación de las organizaciones y puede utilizarse además como referencia para nuevas implementaciones relacionadas con la seguridad de la información. ISSAF está organizado según unos criterios de evaluación bien definidos,  cada uno de estos ha sido revisado por expertos en la matería entre estos expertos podemos encontrarnos a Balwant Rathore, Mark Brunner, Piero Brunati, Arturo Busleiman (Buanzo), Hernán Marcelo Racciatti, Andrés Riancho, entre otros.

Los criterios de evaluación incluyen los siguientes:

  • Una descripción de los criterios de evaluación
  • Finalidades y objetivos
  • Los prerrequisitos para la realización de las evaluaciones
  • Los procesos para las evaluaciones
  • Presentación de resultados
  • Contramedidas recomendadas
  • Referencias a documentos externos

ISSAF propone cinco fases para la realización de un completo Test de Penetración:

  • Fase I – Planeación
  • Fase II – Evaluación
  • Fase III – Tratamiento
  • Fase IV – Acreditación
  • Fase V – Mantenimiento

Cada una de estas fases involucra muchos procesos, entre muchos de ellos los siguientes: Recolección de Información, Identificación de Recursos, Riesgos Inherentes, Regulaciones Legales, Políticas de Seguridad, Evaluaciones, Mapeo de Red, Identificación de Vulnerabilidades, Penetración, Obteniendo Acceso, Escalada de Privilegios, Mantenimiento del Acceso, Cubrimiento de Huellas y Reportes.

Más información y descarga ISSAF >>


OSSTMM – Open Source Security Testing Methodology Manual

Posted by 4v4t4r On octubre - 15 - 2009

Manual de la Metodología Abierta de Testeo de Seguridad

Es un conjunto de reglas y lineamientos para CUANDO, QUE y CUALES eventos son testeados. Esta metodología cubre únicamente el testeo de seguridad externo, es decir, testear la seguridad desde un entorno no privilegiado hacia un entorno privilegiado, para evadir los componentes de seguridad, procesos y alarmas y ganar acceso privilegiado. Está también dentro del alcance de este documento proveer un método estandarizado para realizar un exhaustivo test de seguridad de cada sección con presencia de seguridad (por ejemplo, seguridad física, seguridad inalámbrica, seguridad de comunicaciones, seguridad de la información, seguridad de las tecnologías de Internet, y seguridad de procesos) de una organización. Dentro de este método abierto y evaluado por expertos, para realizar exhaustivos testeos de seguridad, alcanzamos un estándar internacional en testeos de seguridad, que representa una línea de referencia para todas las metodologías de testeo de seguridad tanto conocidas como inexploradas.

La limitación al alcance del testeo de seguridad externo está dada por las diferencias considerables entre testeo externo a interno y testeo interno a interno. Estas diferencias radican fundamentalmente en los privilegios de acceso, los objetivos, y los resultados asociados con el testeo interno a interno.
El tipo de testeo que busca descubrir las vulnerabilidades inexploradas no está dentro del alcance de este documento ni dentro del alcance de un test de seguridad OSSTMM. El test de seguridad descrito a continuación es un test práctico y eficiente de vulnerabilidades conocidas, filtraciones de información, infracciones de la ley, estándares de la industria y prácticas recomendadas.

ISECOM exige que un test de seguridad solamente sea considerado un test OSSTMM si es:

  • Cuantificable.
  • Consistente y que se pueda repetir.
  • Válido mas allá del período de tiempo “actual”.
  • Basado en el mérito del testeador y analista, y no en marcas comerciales.
  • Exhaustivo.
  • Concordante con leyes individuales y locales y el derecho humano a la privacidad.

ISECOM no asevera que el uso del OSSTMM constituya una protección legal en todos los tribunales de justicia, sin embargo, cumple el papel del más alto nivel de profesionalismo en cuanto a testeos de seguridad cuando los resultados obtenidos son aplicados al perfeccionamiento de la seguridad dentro de un espacio de tiempo razonable.

Más información OSSTMM >>

Descargar OSSTMM – Español >>

Download OSSTMM – English >>