Information Systems Security

The Open Source Security Testing Methodology

The Information Systems Security Assessment Framework (ISSAF) seeks to integrate the following management tools and internal control checklists:

Evaluate the organizations information security policies & processes to report on their compliance with IT industry standards, and applicable laws and regulatory requirements
Identify and assess the business dependencies on infrastructure services provided by IT
Conduct vulnerability assessments & penetration tests to highlight system vulnerabilities that could result in potential risks to information assets
Specify evaluation models by security domains to :
Find mis-configurations and rectify them
Identifying risks related to technologies and addressing them
Identifying risks within people or business processes and addressing them
Strengthening existing processes and technologies
Provide best practices and procedures to support business continuity initiatives

Business Benefits of ISSAF

The ISSAF is intended to comprehensively report on the implementation of existing controls to support IEC/ISO 27001:2005(BS7799), Sarbanes Oxley SOX404, CoBIT, SAS70 and COSO, thus adding value to the operational aspects of IT related business transformation programmes.
Its primary value will derive from the fact that it provides a tested resource for security practitioners thus freeing them up from commensurate investment in commercial resources or extensive internal research to address their information security needs.
It is designed from the ground up to evolve into a comprehensive body of knowledge for organizations seeking independence and neutrality in their security assessment efforts.

It is the first framework to provide validation for bottom up security strategies such as penetration testing as well as top down approaches such as the standardization of an audit checklist for information policies.

The Open Web Application Security Project (OWASP) is an open-source application security project. The OWASP community includes corporations, educational organizations, and individuals from around the world. This community works to create freely-available articles, methodologies, documentation, tools, and technologies. The OWASP Foundation is a 501(c)(3)charitable organization that supports and manages OWASP projects and infrastructure. It is also a registered non profit in Europe since June 2011.

OWASP is not affiliated with any technology company, although it supports the informed use of security technology. OWASP has avoided affiliation as it believes freedom from organizational pressures may make it easier for it to provide unbiased, practical, cost-effective information about application security.[citation needed] OWASP advocates approaching application security by considering the people, process, and technology dimensions.

OWASP’s most successful documents include the book-length OWASP Guide,[1] the OWASP Code Review Guide OWASP Guide [2] and the widely adopted Top 10 awareness document.[3][citation needed] The most widely used OWASP tools include their training environment,[4] their penetration testing proxy WebScarab,[5] and their .NET tools.[6] OWASP includes roughly 190 local chapters [7] around the world and thousands of participants on the project mailing lists. OWASP has organized the AppSec [8] series of conferences to further build the application security community.

OWASP is also an emerging standards body, with the publication of its first standard in December 2008, the OWASP Application Security Verification Standard (ASVS).[9] The primary aim of the OWASP ASVS Project is to normalize the range of coverage and level of rigor available in the market when it comes to performing application-level security verification. The goal is to create a set of commercially workable open standards that are tailored to specific web-based technologies. A Web Application Edition has been published. A Web Service Edition is under development.

the OWASP Top Ten Project – if you’re looking for the OWASP Top 10 Mobile Click Here
The Release Candidate for the OWASP Top 10 for 2013 is now available here: OWASP Top 10 – 2013 – Release Candidate

The OWASP Top 10 – 2013 Release Candidate includes the following changes as compared to the 2010 edition:

  • A1 Injection
  • A2 Broken Authentication and Session Management (was formerly A3)
  • A3 Cross-Site Scripting (XSS) (was formerly A2)
  • A4 Insecure Direct Object References
  • A5 Security Misconfiguration (was formerly A6)
  • A6 Sensitive Data Exposure (merged from former A7 Insecure Cryptographic Storage and former A9 Insufficient Transport Layer Protection)
  • A7 Missing Function Level Access Control (renamed/broadened from former A8 Failure to Restrict URL Access)
  • A8 Cross-Site Request Forgery (CSRF) (was formerly A5)
  • A9 Using Known Vulnerable Components (new but was part of former A6 – Security Misconfiguration)
  • A10 Unvalidated Redirects and Forwards

Please review this release candidate and provide comments to or to the OWASP Top 10 mailing list (which you must be subscribed to). The comment period is open from Feb 16 through March 30, 2013 and a final version will be released in May 2013.

If you are interested, the methodology for how the Top 10 is produced is now documented here: OWASP Top 10 Development Methodology

OWASP Appsec Tutorial Series

Uploaded on Jan 30, 2011
The first episode in the OWASP Appsec Tutorial Series. This episode describes what the series is going to cover, why it is vital to learn about application security, and what to expect in upcoming episodes.

Uploaded on Feb 8, 2011
The second episode in the OWASP Appsec Tutorial Series. This episode describes the #1 attack on the OWASP top 10 – injection attacks. This episode illustrates SQL Injection, discusses other injection attacks, covers basic fixes, and then recommends resources for further learning.

Uploaded on Jul 11, 2011
The third episode in the OWASP Appsec Tutorial Series. This episode describes the #2 attack on the OWASP top 10 – Cross-Site Scripting (XSS). This episode illustrates three version of an XSS attack: high level, detailed with the script tag, and detailed with no script tag, and then recommends resources for further learning.

Published on Sep 24, 2012
The forth episode in the OWASP Appsec Tutorial Series. This episode describes the importance of using HTTPS for all sensitive communication, and how the HTTP Strict Transport Security header can be used to ensure greater security, by transforming all HTTP links to HTTPS automatically in the browser.

DEFT 7 is based on the new Kernel 3 (Linux side) and the DART (Digital Advanced Response Toolkit) with the best freeware Windows Computer Forensic tools. It’s a new concept of Computer Forensic system that use LXDE as desktop environment and WINE for execute Windows tools under Linux and mount manager as tool for device management.

It is a very professional and stable system that includes an excellent hardware detection and the best free and open source applications dedicated to Incident Response, Cyber Intelligence and Computer Forensics.

DEFT is meant to be used by:

IT Auditors

DEFT is 100% made in Italy

Natas; Crónica del virus mexicano

Tomado de

En 1992 Little Loc se registro en Prodigy para buscar información sobre virii. Little Loc, alias James Gentile, a los 16 años habí­a escrito un virus mutante que se dispersaba rápidamente. El virus, Satan Bug, estaba escrito de manera que el proceso mismo de rastrear un disco en busca de infección infectaba todos los ejecutables en el mismo.

Satan Bug era el nombre de una teleserie de los 70s. ((Aunque Little Loc nunca vio la serie, vio el nombre en el TVguí­a y le gusto. )) El icono que inspiro la creación de Satan Bug fue el trabajo de Dark Avenger, ((un programador búlgaro de virus y su virus Eddie o Dark Avenger. Eddie usaba los mecanismos de rastreo de antivirus para infectar una maquina y gradualmente corrompí­a el disco duro del anfitrión. Una muerta lenta y dolorosa bajo las cuchillas del vengador tenebroso.))

Little Loc tenía talento natural para escribir virii, un arte que aprendió sin maestro directo ni entrenamiento formal en programación. ((Siguiendo el modelo de Eddie, Satan Bug atacaba el command shell al instalarse en memoria.)) Adicionalmente a los poderes del vengador tenebroso, Satan bug estaba encriptado y se escondí­a en la memoria del computador. Las características de encriptación estaban basadas en la ballena, un virus alemán. La ballena era una pesada navaja suiza de trucos para esconderse de los antivirus.

Little Loc publico el código fuente de Satan Bug en un boletín de noticias y se dedico activamente a diseminar su código. ((Su motivación era ser reconocido por su habilidad técnica.)) Eventualmente, en 1993, Satan Bug infecto las maquinas del servicio secreto en Washington D.C. y las saco de servicio por 3 dí­as. El servicio secreto siguió una línea de investigación con la hipótesis de que el virus era un esfuerzo deliberado para atacar maquinas del gobierno de Estados Unidos.

Little Loc cambió su nombre por Priest y escribió Jackal. ((Jackal fue escrito como un contraataque contra TBClean, un antivirus producido por la compañí­a holandesa Thunderbyte, del investigador de virus Frans Veldman.)) Un derivado de Jackal fue el Natas. En su espí­ritu de medida retaliatoria, Natas formatea el disco duro cuando detecta la presencia de TBClean.

Los mecanismos de detección de programas antivirus de Jackal los incluyo Priest en Natas (Satan al revés), que llego a la ciudad de México en la primavera de 1994.

De acuerdo a la tradición, un consultor que vendía servicios antivirus en la ciudad de México se encargo de propagarlo vigorosamente. Debido a ignorancia e incompetencia, adicionada con entusiasmo empresarial y poder de convocatoria, este pendejo con iniciativa logro difundir Natas en México tan rápido que la leyendo urbana lo ubica como un software de origen mexicano. Un script tragicómico digno del mejor guionista.

El consultor, al visitar los boletines de noticias dedicados a virii, contamino un diskette con Natas. ((El software que usaba detectaba el virus en programas, pero no en el sector MBR (Master Boot Record) del disco duro.)) El consultor iba con sus clientes, corrí­a su software de rastreo de su diskette infectado y detectaba la infección de Natas que el mismo provocaba. Alarmado corría a la siguiente maquina y repetía el proceso, infectando todas las maquinas del lugar. Inmediatamente iba a visitar a sus mejores clientes con la noticia de que había una epidemia de Natas y que más les valía rastrear sus maquinas, con el software que el traí­a, que podía detectar al Natas. Entonces procedía a infectar todas las maquinas y a continuar el proceso con el vecino de al lado. Seguramente penso que eso de Satan iba ne sero cuando despues de formatar las maquinas el virus resurguía de la nada. Espeluznante!

Natas llego a México del sur de California. El consultor era visitante frecuente de BBS en Santa Clarita que tenían el Natas y su código fuente en la revista 40Hex. El buen cuate bajo el virus sin entender que al diablo le puedes vender el alma, pero no pedirla de regreso. En mayo de 1994, un mes después, desesperadamente el consultor buscaba ayuda en los boletines de noticias.

Natas era un programa tí­pico de Priest. Estando en memoria, hace parecer que programas infectados no lo estaban. Copia una copia limpia de MBR y se la muestra al usuario para fintarlo de que todo estaba bien si lo revisa. Natas infectaba diskettes y utiliza el rastreo del antivirus para diseminarse.

Yo en lo personal tuve una experiencia similar a la del cuento. Tenia una Compaq Presario que me estaba dando problemas y solicite la vista de un técnico de Compaq para que revisara la maquina. El técnico se tuvo que retirar sin dar le servicio porque todos sus diskettes con utilerías de diagnostico estaban infectados con un virus.

Ubuntu root

Con un enfoque paternalista Ubuntu de entrada no da acceso a la cuenta de  root, sino que los comandos privilegiados se deben ejecutar usando sudo. Since most Ubuntu documentation asks you to use sudo even with graphical applications, Why recommend gksudo or kdesudo for graphical applications instead of sudo.

For example, a lot of guides (including the first book ever published about Ubuntu) will ask you to type this sort of command:

sudo gedit /etc/apt/sources.list

I will always recommend, however, that people use instead this sort of command:

gksudo gedit /etc/apt/sources.list

And reserve sudo for command-line applications, like so:

sudo nano /etc/apt/sources.list

Why is it an issue?
Well, to be perfectly honest, most of the time it isn’t. For a lot of applications, you can run them the improper way—using sudo for graphical applications and see no adverse side effects.

1. There are other times, though, when side effects can be as mild as Firefox extensions not sticking or as extreme as as not being able to log in any more because the permissions on your .ICEauthority changed. You can read a full discussion on the issue here.

These errors occur because sometimes when sudo launches an application, it launches with root privileges but uses the user’s configuration file.


Alternate Operating System Scanner

What is PC Tools’ Alternate Operating System Scanner?

Once a system is infected with malware it becomes difficult to remove that malware as it is already embedded in the system and has control over many components which are key to the system’s operations. Malware, like rootkits, use system components to hide themselves and prevent other software from detecting or removing them. This is often the case of who gets there first; if the malware is able to get control of the system earlier on then it also has control over any software that may be run later. Besides just hiding, malware can also block the execution of other security applications. If you cannot install or run a security application in the first place then you cannot scan and detect the malware. The best time to remove this malware is when it is not running, but malware often starts with the Operating System, so we would have to stop the Operating System to stop the malware. On a shutdown OS nothing is running and malware like rootkits cannot hide themselves and so it would be easy to find and remove them.


Israel y Estados Unidos desarrollaron técnicas para atacar sistemas de control industrial con el propósito de fastidiar a Irán,pero el secreto es saber que se puede y ahora el genio se salio de la lampara

SAN JOSE, Calif. (AP) — When a computer attack hobbled Iran‘s unfinished nuclear power plant last year, it was assumed to be a military-grade strike, the handiwork of elite hacking professionals with nation-state backing.
Yet for all its science fiction sophistication, key elements have now been replicated in laboratory settings by security experts with little time, money or specialized skill. It is an alarming development that shows how technical advances are eroding the barrier that has long prevented computer assaults from leaping from the digital to the physical world.
The techniques demonstrated in recent months highlight the danger to operators of power plants, water systems and othercritical infrastructure around the world.
“Things that sounded extremely unlikely a few years ago are now coming along,” said Scott Borg, director of the U.S. Cyber Consequences Unit, a nonprofit group that helps the U.S. government prepare for future attacks.
While the experiments have been performed in laboratory settings, and the findings presented at security conferences or in technical papers, the danger of another real-world attack such as the one on Iran is profound.
The team behind the so-called Stuxnet worm that was used to attack the Iranian nuclear facility may still be active. New malicious software with some of Stuxnet’s original code and behavior has surfaced, suggesting ongoing reconnaissance against industrial control systems.
And attacks on critical infrastructure are increasing. The Idaho National Laboratory, home to secretive defense labs intended to protect the nation’s power grids, water systems and other critical infrastructure, has responded to triple the number of computer attacks from clients this year over last, the U.S. Department of Homeland Security has revealed.
For years, ill-intentioned hackers have dreamed of plaguing the world’s infrastructure with a brand of sabotage reserved for Hollywood. They’ve mused about wreaking havoc in industrial settings by burning out power plants, bursting oil and gas pipelines, or stalling manufacturing plants.
But a key roadblock has prevented them from causing widespread destruction: they’ve lacked a way to take remote control of the electronic “controller” boxes that serve as the nerve centers for heavy machinery.
The attack on Iran changed all that. Now, security experts — and presumably, malicious hackers — are racing to find weaknesses. They’ve found a slew of vulnerabilities.
Think of the new findings as the hacking equivalent of Moore’s Law, the famous rule about computing power that it roughly doubles every couple of years. Just as better computer chips have accelerated the spread of PCs and consumer electronics over the past 40 years, new hacking techniques are making all kinds of critical infrastructure — even prisons — more vulnerable to attacks.
One thing all of the findings have in common is that mitigating the threat requires organizations to bridge a cultural divide that exists in many facilities. Among other things, separate teams responsible for computer and physical security need to start talking to each other and coordinate efforts.
Many of the threats at these facilities involve electronic equipment known as controllers. These devices take computer commands and send instructions to physical machinery, such as regulating how fast a conveyor belt moves.
They function as bridges between the computer and physical worlds. Computer hackers can exploit them to take over physical infrastructure. Stuxnet, for example, was designed to damage centrifuges in the nuclear plant being built in Iran by affecting how fast the controllers instructed the centrifuges to spin. Iran has blamed the U.S. and Israel for trying to sabotage what it says is a peaceful program.
Security researcher Dillon Beresford said it took him just two months and $20,000 in equipment to find more than a dozen vulnerabilities in the same type of electronic controllers used in Iran. The vulnerabilities, which included weak password protections, allowed him to take remote control of the devices and reprogram them.
“What all this is saying is you don’t have to be a nation-state to do this stuff. That’s very scary,” said Joe Weiss, an industrial control system expert. “There’s a perception barrier, and I think Dillon crashed that barrier.”
One of the biggest makers of industrial controllers is Siemens AG, which made the controllers in question. The company said it has alerted customers, fixed some of the problems and is working closely with CERT, the cybersecurity arm of the U.S. Department of Homeland Security.
Siemens said the issue largely affects older models of controllers. Even with those, the company said, a hacker would have to bypass passwords and other security measures that operators should have in place. Siemens said it knows of no actual break-ins using the techniques identified by Beresford, who works in Austin, Texas, for NSS Labs Inc.,
Yet because the devices are designed to last for decades, replacing or updating them isn’t always easy. And the more research that comes out, the more likely attacks become.
One of the foremost Stuxnet experts, Ralph Langner, a security consultant in Hamburg, Germany, has come up with what he calls a “time bomb” of just four lines of programming code. He called it the most basic copycat attack that a Stuxnet-inspired prankster, criminal or terrorist could come up with.
“As low-level as these results may be, they will spread through the hacker community and will attract others who continue digging,” Langer said in an email.
The threat isn’t limited to power plants. Even prisons and jails are vulnerable.
Another research team, based in Virginia, was allowed to inspect a correctional facility — it won’t say which one — and found vulnerabilities that would allow it to open and close the facility’s doors, suppress alarms and tamper with video surveillance feeds.
During a tour of the facility, the researchers noticed controllers like the ones in Iran. They used knowledge of the facility’s network and that controller to demonstrate weaknesses.
They said it was crucial to isolate critical control systems from the Internet to prevent such attacks.
“People need to deem what’s critical infrastructure in their facilities and who might come in contact with those,” Teague Newman, one of the three behind the research.
Another example involves a Southern California power company that wanted to test the controllers used throughout its substations. It hired Mocana Corp., a San Francisco-based security firm, to do the evaluation.
Kurt Stammberger, a vice president at Mocana, told The Associated Press that his firm found multiple vulnerabilities that would allow a hacker to control any piece of equipment connected to the controllers.
“We’ve never looked at a device like this before, and we were able to find this in the first day,” Stammberger said. “These were big, major problems, and problems frankly that have been known about for at least a year and a half, but the utility had no clue.”
He wouldn’t name the utility or the device maker. But he said it wasn’t a Siemens device, which points to an industrywide problem, not one limited to a single manufacturer.
Mocana is working with the device maker on a fix, Stammberger said. His firm presented its findings at the ICS Cyber Security Conference in September.
Even if a manufacturer fixes the problem in new devices, there’s no easy way to fix it in older units, short of installing new equipment. Industrial facilities are loath to do that because of the costs of even temporarily shutting its operations.
“The situation is not at all as bad as it was five to six years ago, but there’s much that remains to be done,” said Ulf Lindqvist, an expert on industrial control systems with SRI International. “We need to be as innovative and organized on the good-guy side as the bad guys can be.”
Jordan Robertson can be reached at jrobertson(at)


To say it straight in only one sentence: gpg4usb is a very easy to use portable-application, which combines a simple text-editor with a GnuPG-frontend to write, encrypt and decrypt your text-messages and files. gpg4usb should work on almost any computer you’re working on, should it be a Linux-machine or even one with a Microsoft-OS running.

Almost the only thing required is an available usb-port you are allowed to access. With this application you can write safe and encrypted messages anywhere you are: should it be an internet-cafe, at work or somewhere else on holiday… and you always have the encryption-keys available for usage!

The usage of gpg4usb should be highly self-describing, since the user-interface and all the options it offers are clear cut: Simply execute the binary on your usb-pendrive and start typing e.g. the Mailtext you want to be encrypted. If you’re done, choose the right gpg/pgp-key for the person you are writing to and hit the encrypt-icon at the top of the application-window. The resulting encrypted text you can save as a text-file to send it as mail-attachment, or copy it directly into your mail-user-agent or webmail-website. To make sure, you can read this message by yourself afterwards, encrypt it for the recipient and to yourself at the same time – if you want, you can mark as much keys as you want to encrypt for.

You want to add a gpg/pgp-key to your mobile keyring? Nothing’s easier than that: just hit the crypto-menue-entry and choose Import Key from File or Import Key from Editor. This means that it’s possible to import an ascii-armored pubkey via file-dialog, or via copy&paste into your editor-window. If you find a key e.g. on a website, just copy it, paste it into the gpg4usb-editor and hit Import Key from Editor – that’s it, and the key shows up on your keyring!

Pasted from <>


You can get our latest Release v0.3.2 by clicking the download link below. Since v0.2.4 the included executables are upx-compressed by default.

Filename Size* sha1 14.8MB / 18.6MB efeeaeff2883ded6abfe6378113c219e5e897bb0

* Size zipped / unzipped

Just download the zip-File and unzip it onto your usb-pendrive. Then simply change into the folder gpg4usb at your usb-drive, and execute the binary in there:

start_linux or start_windows.exe – should be easy to determine, which one’s yours 😉

Since gpg4usb is free software, licensed under the GNU General Public License (GPL), you can use it on as many machines as you want. Copy it, modify and redistribute it, give gpg4usb to as many people as possible! 

Pasted from <>

ISO/IEC 27001

ISO/IEC 27001, part of the growing ISO/IEC 27000 family of standards, is an information security management system (ISMS) standard published in October 2005 by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). Its full name is ISO/IEC 27001:2005 – Information technology – Security techniques – Information security management systems – Requirements.

ISO/IEC 27001 formally specifies a management system that is intended to bring information security under explicit management control. Being a formal specification means that it mandates specific requirements. Organizations that claim to have adopted ISO/IEC 27001 can therefore be formally audited and certified compliant with the standard (more below).

Most organizations have a number of information security controls. However, without an information security management system (ISMS), controls tend to be somewhat disorganized and disjointed, having been implemented often as point solutions to specific situations or simply as a matter of convention. Security controls in operation typically address certain aspects of IT or data security specifically; leaving non-IT information assets (such as paperwork and proprietary knowledge) less protected on the whole. Moreover business continuity planning and physical security may be managed quite independently of IT or information security while Human Resources practices may make little reference to the need to define and assign information security roles and responsibilities throughout the organization.

ISO/IEC 27001 requires that management:

  • Systematically examine the organization’s information security risks, taking account of the threats, vulnerabilities, and impacts;
  • Design and implement a coherent and comprehensive suite of information security controls and/or other forms of risk treatment (such as risk avoidance or risk transfer) to address those risks that are deemed unacceptable; and
  • Adopt an overarching management process to ensure that the information security controls continue to meet the organization’s information security needs on an ongoing basis.

The key benefits of 27001 are:

  • It can act as the extension of the current quality system to include security
  • It provides an opportunity to identify and manage risks to key information and systems assets
  • Provides confidence and assurance to trading partners and clients; acts as a marketing tool
  • Allows an independent review and assurance to you on information security practices

A company may want to adopt ISO 27001 for the following reasons:

  • It is suitable for protecting critical and sensitive information
  • It provides a holistic, risked-based approach to secure information and compliance
  • Demonstrates credibility, trust, satisfaction and confidence with stakeholders, partners, citizens and customers
  • Demonstrates security status according to internationally accepted criteria
  • Creates a market differentiation due to prestige, image and external goodwill
  • If a company is certified once, it is accepted globally.

While other sets of information security controls may potentially be used within an ISO/IEC 27001 ISMS as well as, or even instead of, ISO/IEC 27002 (the Code of Practice for Information Security Management), these two standards are normally used together in practice. Annex A to ISO/IEC 27001 succinctly lists the information security controls from ISO/IEC 27002, while ISO/IEC 27002 provides additional information and implementation advice on the controls. The domains covered by ISO 27002 include

Organizations that implement a suite of information security controls in accordance with ISO/IEC 27002 are simultaneously likely to meet many of the requirements of ISO/IEC 27001, but may lack some of the overarching management system elements. The converse is also true, in other words, an ISO/IEC 27001 compliance certificate provides assurance that the management system for information security is in place, but says little about the absolute state of information security within the organization. Technical security controls such as antivirus and firewalls are not normally audited in ISO/IEC 27001 certification audits: the organization is essentially presumed to have adopted all necessary information security controls since the overall ISMS is in place and is deemed adequate by satisfying the requirements of ISO/IEC 27001. Furthermore, management determines the scope of the ISMS for certification purposes and may limit it to, say, a single business unit or location. The ISO/IEC 27001 certificate does not necessarily mean the remainder of the organization, outside the scoped area, has an adequate approach to information security management.

Other standards in the ISO/IEC 27000 family of standards provide additional guidance on certain aspects of designing, implementing and operating an ISMS, for example on information security risk management (ISO/IEC 27005).

The ISO 27001 adopts the process model “Plan-Do-Check-Act” (PDCA) which is applied to the structure of all the processes in ISMS.

BS 7799 was a standard originally published by BSI Group[1] in 1995. It was written by the United Kingdom Government’s Department of Trade and Industry (DTI), and consisted of several parts.

The first part, containing the best practices for information security management, was revised in 1998; after a lengthy discussion in the worldwide standards bodies, it was eventually adopted by ISO as ISO/IEC 17799, “Information Technology – Code of practice for information security management.” in 2000. ISO/IEC 17799 was then revised in June 2005 and finally incorporated in the ISO 27000 series of standards as ISO/IEC 27002 in July 2007.

The second part of BS7799 was first published by BSI in 1999, known as BS 7799 Part 2, titled “Information Security Management Systems – Specification with guidance for use.” BS 7799-2 focused on how to implement an Information security management system (ISMS), referring to the information security management structure and controls identified in BS 7799-2. This later became ISO/IEC 27001. The 2002 version of BS 7799-2 introduced the Plan-Do-Check-Act (PDCA) cycle (Deming cycle), aligning it with quality standards such as ISO 9000. BS 7799 Part 2 was adopted by ISO as ISO/IEC 27001 in November 2005.

BS 7799 Part 3 was published in 2005, covering risk analysis and management. It aligns with ISO/IEC 27001.

Plan (establishing the ISMS)
Establish the policy, the ISMS objectives, processes and procedures related to risk management and the improvement of information security to provide results in line with the global policies and objectives of the organization.
Do (implementing and workings of the ISMS)
Implement and exploit the ISMS policy, controls, processes and procedures.
Check (monitoring and review of the ISMS)
Assess and, if applicable, measure the performances of the processes against the policy, objectives and practical experience and report results to management for review.
Act (update and improvement of the ISMS)
Undertake corrective and preventive actions, on the basis of the results of the ISMS internal audit and management review, or other relevant information to continually improve the said system.
An ISMS may be certified compliant with ISO/IEC 27001 by a number of Accredited Registrars worldwide. Certification against any of the recognized national variants of ISO/IEC 27001 (e.g. JIS Q 27001, the Japanese version) by an accredited certification body is functionally equivalent to certification against ISO/IEC 27001 itself.In some countries, the bodies that verify conformity of management systems to specified standards are called “certification bodies”, while in others they are commonly referred to as “registration bodies”, “assessment and registration bodies”, “certification/ registration bodies”, and sometimes “registrars”.The ISO/IEC 27001 certification,[2] like other ISO management system certifications, usually involves a three-stage external audit process:

  • Stage 1 is a preliminary, informal review of the ISMS, for example checking the existence and completeness of key documentation such as the organization’s information security policy, Statement of Applicability (SoA) and Risk Treatment Plan (RTP). This stage serves to familiarize the auditors with the organization and vice versa.
  • Stage 2 is a more detailed and formal compliance audit, independently testing the ISMS against the requirements specified in ISO/IEC 27001. The auditors will seek evidence to confirm that the management system has been properly designed and implemented, and is in fact in operation (for example by confirming that a security committee or similar management body meets regularly to oversee the ISMS). Certification audits are usually conducted by ISO/IEC 27001 Lead Auditors. Passing this stage results in the ISMS being certified compliant with ISO/IEC 27001.
  • Stage 3 involves follow-up reviews or audits to confirm that the organization remains in compliance with the standard. Certification maintenance requires periodic re-assessment audits to confirm that the ISMS continues to operate as specified and intended. These should happen at least annually but (by agreement with management) are often conducted more frequently, particularly while the ISMS is still maturing.

Asset Management

The asset management domain deals with analyzing and attaining the necessary level of protection of organizational assets. The typical objectives of the asset management domain is to identify and create an inventory of all assets, establish an ownership on all assets identified, establish a set of rules for the acceptable use of assets, establish a framework for classification of assets, establish an asset labeling and handling guideline. Asset management, broadly defined, refers to any system that monitors and maintains things of value to an entity or group. It may apply to both tangible assets such as buildings and to intangible concepts such as intellectual property and goodwill.

An asset is anything that has value to the organization. Assets can include infrastructure (e.g. buildings, store houses, towers etc.), physical assets ( computer equipment, communications, utility equipment, heavy machinery), software assets ( applications, software code, development tools, operational software etc.), information (database information, legal documentation, manuals, policies & procedures, organizational documents etc.), services ( transport, air conditioning, communications, utilities etc.), people (management, skills, experience etc.) and imperceptible (reputation, image etc.).

Asset management is a systematic process of operating, maintaining, upgrading, and disposing of assets cost-effectively. Organizations need to identify all assets and create and maintain security controls around them. For each asset a designated owner needs to be made responsible for implementation of appropriate security controls. When creating an asset management policy the organization needs to define the scope of the policy (which parts of the organization are covered under the policy), responsibility (who is ultimately responsible for the policy), compliance (is compliance mandatory or not, what are the guidelines to follow), wavier criteria (on what basis can someone ask for a waiver) and effective date (from when to when is the policy applicable).

  • Typical policy statements for Asset Management include:
  * All assets shall be clearly identified, documented and regularly updated in an asset register
  * All assets of shall have designated owners and custodians listed in the asset register
  * All assets will have the respective CIA (Confidentiality, Integrity and Availability) rating established in the asset register
  * All employees shall use company assets according to the acceptable use of assets procedures
  * All assets shall be classified according the asset classification guideline of the company

Asset management comprises of all the activities associated with ongoing management and tracking of assets some of which are as follows: asset discovery (physical & logical), create & maintain conclusive software library, create & maintain conclusive hardware stock, configuration management, physical asset tracking, software license management, request & approval process, procurement management, contract management, assessment on ISO 27001 and PCI controls, supplier/ vendor management, re-deployment & movement, retire & disposal Management, compliance to laws if applicable etc.

Asset Register

The asset register documents the assets of the company or scope in question. Typically all business functions are required to maintain an asset register of their business units. The asset register is required to contain, at a minimum, the following information about the assets: the asset identifier, the asset name, the type and location of assets; the name of the function and process that uses this asset, the asset owner, custodian and user and the CIA (Confidentiality, Integrity, Availability) ratings of the asset. Organizations can choose to additional information into the asset register as necessary for example for IT assets can have IP address as part of them etc.

For all asset registers, a primary person responsible for the asset register needs to be identified. Typically the business unit head or director is the owner of the asset register and recognized functional heads identified are asset custodians. The asset owner is accountable for the comprehensive protection of assets owned by him/her. The asset owner may delegate the responsibility of applying the relevant controls for the maintenance of the assets to an individual/ function referred to as the ‘asset custodian’. It is the responsibility of the asset custodian to implement appropriate security controls that are required for the protection of information assets. It is the responsibility of all employees and third party staff to maintain the confidentiality, integrity and availability of the assets that they use.

Asset Classification

Assets need to be classified in order to provide an appropriate level of protection for a certain category of assets. Information assets need to be classified in terms of its value, requirements and criticality to the business operations of the company. Typical company classification guidelines follow restrictive principles. Some of the common classifications criteria which are used by companies are given below:

RESTRICTED: The restricted level of asset information pertains to highly sensitive information to the company; which when disclosed would cause substantial damage to the reputation and competitive position of the company in the market. Its unauthorized disclosure could adversely impact its business, its shareholders, its business partners and/ or its customers, leading to legal and financial repercussions and adverse public opinion. Examples of restricted information are details of major acquisitions, divestments and mergers, business and competition strategy, sensitive customer, competitor, partner or contractor assessments, intellectual property information, law enforcement and government related information.

CONFIDENTIAL: This category refers to asset information that relates to individuals or is otherwise restricted only to authorized users, but if disclosed outside the company would not harm the organization, its customers, or its partners. This classification applies to any sensitive business information which is intended for use within the company. Examples of confidential information include customer information, negotiating positions, marketing strategy, personnel information, internal company memos and presentations.

INTERNAL This classification refers to asset information that is potentially available to all personnel within the company, but is not public. This can also include information that is restricted to a group or project within the company, but is not designated as “Private” or “Restricted.” Examples of internal information include product design information, system documentation, company employee details, company organizational charts, minutes of department meetings.

PUBLIC This classification refers to asset information that has been published or obtainable from a published source, e.g. the Internet. Example of public information include published marketing material, company public statements or announcements, published company performance information, published job vacancies.

Asset Labeling

All important and critical assets to the company shall be labeled physically / electronically as per the information labeling and handling procedures of the company. The asset owners are required to ensure that their assets are appropriately labeled (marked) for ease of identification. This may exclude information classified as ‘public’. For each classification level, the handling procedures should include the assets introduction; secure processing, storage; transmission and destruction. Classification level must be indicted wherever possible for all forms of physical / electronic information that are sensitive in nature. For example: subject of email stamped with “Confidential” etc.

Por empezar fuerte el curso hoy quiero compartir un enlace de gran interes para los dedicados al mundillo de la gestión de la seguridad entorno a la norma ISO 27001.

Dentro de mis protocolos de seguimiento de las normas 27001, 27002 y las publicaciones o comentarios entorno a ella utilizando las alertas de Google, hoy quiero compartir un par de enlaces que proporciona en un documento PDF una traducción no ofical al castellano de las normas ISO 27001 e ISO 27002.

Aunque los enlaces no aparecen refereciados en ninguna página principal de esta Web, Google la enlaza al buscar sobre controles de la ISO 27002.

Dado que puede ser de interés para el público hispanohablante disponer de una versión en nuestro idioma, comparto la url que Google proporciona por si es del interés de todos.
Ambos documentos aclaran que su uso es autorizado sólo para fines didácticos, objetivo que comparte también este blog.
Las urls donde se encuentran son:

the Stuxnet computer worm

When first discovered in 2010, the Stuxnet computer worm posed a baffling puzzle. Beyond its sophistication loomed a more troubling mystery: its purpose. Ralph Langner and team helped crack the code that revealed this digital warhead’s final target. In a fascinating look inside cyber-forensics, he explains how — and makes a bold (and, it turns out, correct) guess at its shocking origins.

Ralph Langner’s Stuxnet Deep Dive is the definitive technical presentation on the PLC attack portion of Stuxnet. He did a good job of showing very technical details in a readable and logical presentation that you can follow in the video if you know something about programming and PLC’s.

The main purpose of Ralph’s talk was to convince the audience with “100% certainty” that Stuxnet was designed specifically to attack the Natanz facility. He does this at least four different ways, and I have to agree there is no doubt.

Ralph Langner is a German control system security consultant. He has received worldwide recognition for his analysis of the Stuxnet malware.

  • Stuxnet worm hits Iranian centrifuges – from mid-2009 to late 2010
  • Iran complains facilities hit by Stars malware – April 2011
  • Duqu trojan hits Iran’s computer systems – November 2011
  • Flame virus targets computers in PCs across the Middle East, including Iran and Israel – June 2012
  • Iran says Stuxnet worm returns – December 2012

Continue reading “the Stuxnet computer worm”